Roster master maybe only has 128kb of language files but what about other modules ?

DF uses get_lang() at boot which is a benefit, however if the file doesn't exists it does nothing.
get_lang() uses require_once() so you don't have to worry about duplication of the file (this is great for blocks that rely on lang files).

So this is the case:

DF: languages/<language>/<modname>.php
- easy to maintain languages since there's no duplication
- easier to delete a language in one go
Nuke: /modules/<modname>/languages/lang-<language>.php
- harder to maintain languages since there's duplication
- easier to delete complete module

Translators who hate language files being all over the place. So in this case it's also you win some you lose some.

DJMaze wrote:

Roster master maybe only has 128kb of language files but what about other modules ?

Actually 6K, the 128K size was all the image graphics (I was just illustrating that the language files are often negligible in size, especially when compared to the other parts of a module). But, as you say, my perspective was very narrow. Taken all together I will concede that the advantages have merit.

DJMaze wrote:

DF uses get_lang() at boot which is a benefit, however if the file doesn't exists it does nothing. get_lang() uses require_once() so you don't have to worry about duplication of the file (this is great for blocks that rely on lang files).

Excellent. I guess I have no more excuses. Thank you for the explanation, you've addressed everything I came up with, and I'm pretty sure I can make this work with my instantiation code with one line and just move the language file.

from a language standpoint i can see why having all lang files grouped together. but then your still going to have to add english only modules and then try to translate a lot of modules yourself. is there a module translation team?

i'm going to have to completely agree with darkgrue here. it would be much more beneficial to have all modules 100% self contained.

windows programs dont always uninstall all files which is why you could completely uninstall every program you've ever installed and your core windows would still be much larger than a fresh reformat. continually junking up your old df installs with outdated files is one thing that i really hate. by self containing them we can preserve file structure and keep everything clean and organized at all times. if it's not done this way then i'm sure the devs have a reason. they know about file structure and logical disk management just as well as the rest of us. just weird how things are arranged in dragonfly sometimes. i'll take it over phpnuke anyday though.

I'd have to agree with keeping modules self contained, it's quite a hassle for developers to keep track of so many different directories (as if all the files wern't enough) and it's even more of a hassle for the user, alot of questions in these forums end up being solved by templates that wern't uploaded, or missing language files, etc

I think as far as the theme structure goes it would be easy enough to do:

Check theme for template -> Display template
If templated not found -> Display from module/module_name/template folder

coppermine and the forums already have this structure, and it's a bit confusing without proper documentation but easier to install, uninstall, and develop

I'd suggest having a "standard" set to go along with the structure that involves

modules/MyModule
-> templates/
-> language/
-> admin/
-> images/

and possibly even a file naming standard to make it easier for those that wish to dig around in the files and edit templates for their own needs

simple structural changes like this would make it easier for the developer and the user together, and reduce overall problems with installation issues

Now, I know in the latest CVS there have been changes to the way the templates are used.

Load themes/MY_THEME/template/whatever.html
Or, if not found
Load themes/default/template/whatever.html

all that would be needed is another 'or':

Or, Load modules/MY_MODULE/template/whatever.html

this would give the theme designers the option of including any templates they want, and gives the module developers an easier time

I should also point out that if a standard set of classes was always used (a full list of core classes is in the wiki) in themes, this would reduce work for theme designers as well, if they do not intend to change the layout of the templates (ex. simple color changes) they could release a small theme with very few files, and still cover all modules since the templates would also be using the standard set of classes.

Now, having said all that I'll once again offer my assistance in actually making these changes if it's found that it would be desirable. I posted the list of core classes in the wiki and have extensive knowledge of the theme system as well as module development.

And I for one will have no problems changing my modules to fit whatever new system or standard is developed.
Which reminds me, the changes I stated above would still be 100% backwards compatible, so nothing would NEED to be redone right away.


/rant

Good points djdevon3.

Sounds logical to me Kuragari.

I've always enjoyed the KISS concept.

Mystic wrote:

Good points djdevon3. Sounds logical to me Kuragari. I've always enjoyed the KISS concept.

make sure concept isn't about music band. (Keep it Simple)

I've split this from the original topic dragonflycms.org/Forum...13818.html since it's all about languages.

Let provide an full explanation why /modules/NAME/languages/lang-*.php is obselete

1. Some modules and maybe more in the future allow multiple instances (see Forums, coppermine, Downloads Pro and News)
If we allowed the mentioned language path and you have 2 blocks on your site where one is for module X and the other for module Y then the debugger is filled with many php warnings regarding "constant already defined" because it loads both language files.

2. How can a block know where to look for a language file if you allow multiple instances or just custom dirs? It doesn't know so /languages/english/mod_name.php is the "fail safe" solution.

3. Duplication of language files only adds a few kb's to diskspace so that's NO issue.

4. Selfcontained module is easy to un/install for devs but see #1 and #2
/modules/NAME/blocks/ would be a solution (is planned) but then still see #1

so if you have a solution for #1 we could turn it back on just as in 8.x and 9.0.x

I have to agree that the points you make are valid and seems like a better way to go as far as languages are concerned.

As far as the module duplication issue, both Pro News and the upcoming version of ImageBoard remove the need to create duplicate modules (unless for a multi-site setup which i have not yet tested)

Personaly I'm going to continue to make my modules as self contained as possible, no duplicates needed, no spare files flying around when not needed. but this is my personal opinion of how it should work, and it's not always the best solution

to fix #1 i've commited a testcase to CVS inside the language loader method.

You must have a file /modules/MOD_NAME/l10n/id.php which contains

PHP:

<?php return 'module_name';

where module_name is your original module directory name lowercase.
For example Downloads Pro will be using 'downloads' and Forums uses 'forums'.

Languages must have the same name as the directories in /language/ like:
/modules/MOD_NAME/l10n/english.php (without the stupid 'lang-' prefix)

a static array inside get_lang() will handle the identification.

Are you all satisfied ?

meh.

/language/english/modulename.php is what i've always used and always will use. I see no point in doing it differently.

Also 6k for a language file is tiny. My points(dot)inc's language file is already 40 something k, and i've barely begun...

If people are going to complain about "oh bot nnnno when i delete that module, as i always do, i have to change directory into the languages to remove it".

But then again thats what they must do for theme tempaltes aswell. So should theme templates all be in /modules/{module_name}/themes/{theme_name}/tmp.html ?

Or do they just leave them there (they could do the same with lang includes), or do they manually remove them (again do the same with lang includes).

The doing it in two different ways was a bit annoying, one way would be better, but if catering for everyone all at once is your (foolish) goal then by all means go for it, just so long as i know for sure that the "no longer in use" lable for the language dir in the dfcms cvs repository is meaningles and invalid, then all's good.

excuse the double post, cannot edit.

Quote::

Load themes/default/template/whatever.html all that would be needed is another 'or': Or, Load modules/MY_MODULE/template/whatever.html

Isn't this pointless? what would that solve. If the tmeplate isn' in the current theme dir then go to a fallback.

Look int he defualt theme dir. But what you are suggesting means that there isn't one in the defualt dir, BUT TI IS IN the module's theme dir. How did it get there? It must've been uploaded with the rest of the module's files.

But wait, there's more! How would it ever get into the default theme dir? Oh that's easy, it get's uplaoded there along with the rest of the module's files.

So really they are mearly alternatives and both offer NO extra protection than eachother, so having both is bloatware, pure and simple.

One or the other, both is mindlessly stupid. Just thought that i'd point that out nice and clearly.

Organisation is important, but the current system is organised (or at least i was always under the impression that it was).

All of these "it can go here, or if not then it goes over there, but if you don't like that then shove it under that or if it looks bad then wear it ontop of your head and run around in circles" type approach simply means that when I want to find a file i must embark on a hunting expidition... albiet a rather short an boring one.

You do see my point don't you? Isn't "one place for any one thing" the best, most organised approach possible?

mc__ wrote:

You do see my point don't you? Isn't "one place for any one thing" the best, most organised approach possible?

"The most organized" is exactly the point.

IMO if the 'default' files are in the module directory with the module they came with, they'll never be orphaned without trying. the 'if this or that' part is simply to make it easier for expandability.

I tend to think of modules as the same thing as 'core' files, theres should be no reason to edit the default files, but there should also be no reason to include templates in every theme for every module.

The language file is trivial, but the same 'organized' approve is needed, you have your default never changed file in the module directory (or wherever) and if needed, a possible second place for edited versions.

DJMaze wrote:

to fix #1 i've commited a testcase to CVS inside the language loader method. You must have a file /modules/MOD_NAME/l10n/id.php which contains PHP: <?php return 'module_name'; where module_name is your original module directory name lowercase. For example Downloads Pro will be using 'downloads' and Forums uses 'forums'. Languages must have the same name as the directories in /language/ like: /modules/MOD_NAME/l10n/english.php (without the stupid 'lang-' prefix) a static array inside get_lang() will handle the identification. Are you all satisfied ?

I think it will be possible to read the "default" module name from the cpg_inst file and the get_lang() should first check and load for /language/english/MODULE_NAME.php where MODULE_NAME will be the directory name of the module and if not fount it will load /language/english/DEAFULT_NAME.php where DEAFULT_NAME will be the module name taken from the cpg.inst file

This will help those who want the same module but they need different definition for other proposes (for example the first copy should say "Add Blog" and the other "Add Poem")

I know cpg.inst isn’t necessary for all modules, but I thing it will be the same situation for modules not having the file /modules/MOD_NAME/l10n/id.php

And I'll go even further by suggesting moving blocks within the module directory (/modules/MOD_NAME/blocks/) so it will be possible the core to be able to identify the block from which module is coming and assign the name to a variable $module_name and be able to have multiple blocks display content for the respective module