Has anyone experienced any issues with the language in some models?

E.g. FAQ, Content, Links module etc.

Some of the words are showing like they are undefined.
e.g. _LINKSMAINCAT etc

This is only after running the CVS and install/upgrade on a current live system.

The forum and Coppermine are ok.

blackmetalcouk wrote:

Has anyone experienced any issues with the language in some models?

Most likely you have versions that do not have the language file for module 'whatever' under language/english/whatever.php
i.e. may still be under modules/whatever/language/lang-english.php

If that is the case simplest quick fix is to rename lang-english.php to whatever.php and relocate it to the language/english/ directory

Phoenix wrote:

blackmetalcouk wrote: Has anyone experienced any issues with the language in some models? Most likely you have versions that do not have the language file for module 'whatever' under language/english/whatever.php i.e. may still be under modules/whatever/language/lang-english.php If that is the case simplest quick fix is to rename lang-english.php to whatever.php and relocate it to the language/english/ directory

Is this going to be the new standard?

Will modules no longer be able to contain their own language files as they will have to be placed within the root language directory?

It has been the "new" standard for a very long time now - what has changed is that you can no longer get away with using the old method.

Is it not better to keep the admin and language files together with the module.

Phoenix wrote:

It has been the "new" standard for a very long time now - what has changed is that you can no longer get away with using the old method.

I thought it was the other way around... I thought that it had been added, not too long ago, to look for language files in the modules directory so to make modules more modular. I must have just misinterpreted what I read, my mistake.

Anyway, I kinda have to agree with blackmetalcouk. It would seem that a module would be more organized and maintained (upgraded) easier, if it contains all of it's files within it's own root level directory.

Actually, let's make sure we're talking about the same thing. I'm asking from an addon module developers point of view. I can see having the various modules that are core laid out in this fashion as the core is root. Should a module not have this same structure (ie. it's own root which contains all of it's files -- module_name/includes, module_name/admin, etc.)?

A second question would be, what is the point of having a modules language file in the root language directory? Or the admin section, for that matter? It serves no other purpose to the core, other than the module (and it's blocks) that it is for.

A comparative analogy, to me anyway, would be like bringing a box of apples (module) into a store (CMS) and, instead of putting the whole box of apples in produce (modules/{module_name}), you put a couple here and a couple there throughout the store. Why?

I'm not trying to be negative... honestly! I really am simply trying to understand the direction we are moving in and why. We, at ForumsPro, have spent a few hours now bringing everything back to the module level as it makes it far easier to maintain, both for us as developers as well as the end user when it comes time to update (or look for files to custom themselves). Now, it looks like we may have to undo some of this work, if I'm reading this thread correctly and language files will no longer function at the module level.

As far I know it was done in 9.0 to keep all language files together, instead of having them all over the place.. I think like it is now is easier to controll then having language files in the module sections too. Just look at phpnuke, it is a mess

Pitcher is correct.
The old way was more trouble to manage then the new way.
Shure everything inside a module would be better controlable in a developers point of view but makes it harder for the customer. Especialy when they add or remove a language.

Not only languages are put in the same directory also theme templates are that way, not to mention rss.

The administration files are moved inside the module itself as it should.

The reasons for these changes compared to our php-nuke roots are based on experience and customer responds.

/modules/MODNAMe/ = module execution
/themes/default/template/MODNAME/ = module output
/languages/english/MODNAME.php = language

It is similar to MVC programming (Model View Controller) but not fully the same although many other programmers think they work with MVC.

Personally, I think it's a bad move as it complicates add-on module installation and removal. A user now has to go to two separate places, rather than just rip out the modules/whatever directory.

I don't mind have the core put all its languages in one basket, but this really is complicating users and developer's of add-on's lives.

Not sure how it complicates installation - only removal

Mind you, admin is now much simplified, and the module install process is already a big plus.

I guess it's about roundabouts and swings.

Well, thanks for the explanation DJ. Although I would still agree with comments such as darkgrue's, I have voiced my opinion and will leave it at that. The core is yours to develop any way you see fit.

Just keep in mind how {expletive removed} off theme developers were when the theme system broke backwards compatability.

Phoenix wrote:

Not sure how it complicates installation - only removal

It complicates installations using my scheme for module instantiation (kinda disappointed no one's commented on that, actually), which all of the module I've written use now. Users will have to separately rename and copy the language file, rather than just making the copy of the module folder.

I can't really see the advantage going back to the old way for anything other than the core, and even then I'm not so sure. Even reading the thread through, I just don't see the benefit. But as others have said, if that's the system, I guess we have no choice. I really wish the Dev Team would reconsider though.

Ehm darkgrue i think you missed a spot in DF 9.x regarding module duplication.
When you duplicate a module the language files get duplicated as well which results in more discspace used.
(like the forums and coppermine for example)

To place all language files inside one location you don't have to duplicate the files FYI:
Don't copy /languages/english/content.php to content2.php
The trick is to use the following in your module code.

PHP:

get_lang('content');

This also reduces the overall duplication of the same language strings cos you could say your module relies on downloads language.

PHP:

get_lang('content'); get_lang('downloads');

I hope you now understand why it's changed a year ago.

DJMaze wrote:

When you duplicate a module the language files get duplicated as well which results in more discspace used.

In the case of Roster master, the language file is 6KB - the image packages that duplicated are 126KB. Yes, it's a waste, but it's well below the noise threshold for anyone who's not running Dragonfly off of an embedded system. Which is why I said there wasn't a compelling reason.

My primary concern was users who stuggle just getting a CMS up and running, let alone the complications of installing the add-ons. I was shooting for something simple, easy to maintain, and transparent to the end user.

DJMaze wrote:

To place all language files inside one location you don't have to duplicate the files FYI: Don't copy /languages/english/content.php to content2.php The trick is to use the following in your module code. PHP: get_lang('content'); This also reduces the overall duplication of the same language strings cos you could say your module relies on downloads language. PHP: get_lang('content'); get_lang('downloads'); I hope you now understand why it's changed a year ago.

Well, not completely. But you did address my primary concern, which is more than fair.

To make sure I understand: the correct way is to install all language files in "language/english/<modulename>.php" (assuming English language files). Then at the (or each) module entry point I need to call get_lang()? I was under the impression that the core was doing that as part of initializing the module? How do I ensure that it doesn't get called or a constant defined twice (constant redefined warnings)?

I'd like to make sure my code is square with respect to doing things correctly, I'm just not sure I understand the actual mechanism well now. Especially since I thought the "old way" was the new way (hence my consternation at the change).

lastest DF already call get_lang since it use module name as value. DF Modules is more like plugin in the CMS. Some Time, you got to break old habit. if constant declare twice, you can comment or changed constant.