Custom language files

[cnb]

Add support for optional custom language files, which can be full (including all string definitions, like the normal language files) or partial (including just some strings). Same structure as the normal language file: an $18n array that would be merged after loading the normal lang file.

This way users could update the plugin (or updating some language file) by just overwriting all files, without worrying about any modifications in language files.

[cnb]

Custom language files could be:

• stored in a new subfolder lang/custom/, same name as the corresponding file in lang/

or

• stored in lang/ but with name xx_YY.custom.php (to be merged after xx_YY.php)

@tablatronix (and anyone else) Which way do you think it's better? Do you think it would be interesting to implement this also in GS?

[tablatronix]

So this would be an ancillary override file for all language tokens. Merge after all langs are loaded, this might be problematic in that plugins can load their languages whenever or however they want.

Might not be able to override it always, We might have to modify i18n functions to check these overrides in real time.

[cnb]

I'm not suggesting that GS does the merge for plugins. It would be only for the core language.

The way I was thinking about this, if a plugin wants to support this it would have to do the merge itself (like I intend to do in NM)

[tablatronix]

hmm, I can see one issue
You won't ever get updates to the language file, since you are overriding them. Users would have to constantly check and update or delete stuff as the main lang file changes over time.

I guess the question is what are you satisfying , users wanting custom wording or more specific wording on a token. or missing token handling, or something else?

[cnb]

Normally you would just override some definitions, e.g. changing the plugin sidebar title to just "News" or "Blog" (instead of "News Manager"), or using the word "article" instead of "post" in several strings... Also redefining LOCALE, frontend strings...

I'd like to know which method of the two you think would be better, lang/xx_YY.custom.php, or lang/custom/xx_YY.php , or if you have a better idea (that is, how would you implement it in GS or in a plugin if you were to do it)

[cnb]

hmm, I can see one issue
You won't ever get updates to the language file, since you are overriding them. Users would have to constantly check and update or delete stuff as the main lang file changes over time.

I think that the meaning of the strings in a language file should not have big changes.
At least in NM I would just add a new string if the meaning was changing substantially.

[tablatronix]

yeah this would be pretty nice for core... was trying to figure out how to implement though.

What really sucks is that these files should probably be outside of plugins and lang, I proposed a data/langs location on github somewhere.

I think a subfolder works better for making any get langs calls easier to fix ( dont have to filter by filenames ), also you don't need special names for files, you can just use paths or symblinks etc.
These can be easily moved or consolidated by modifying paths only.

[cnb]

Thanks, I'll probably go the subfolder way (news_manager/lang/custom/)

[cnb]

Leaving this for later.
In the meantime $nm_i18n array can be used (gsconfig) for this stuff (rel: #108)