...b.ini to use the new mechanism and removed duplicate translations.
Added possibility to use a parent ini file in translations. Changed e…
…n-gb.ini to use the new mechanism and removed duplicate translations.
Removed extraneous spaces (for parity with original en-gb.ini).
A few thoughts on this:
1.) Can we prefix the parent_ini key with a symbol to better differentiate between translation strings and commands and to better sort the two apart? I'm thinking that "@parent_ini" might be a good option.
2.) Doesn't this code currently pose the risk that some of the parent lines will override some of the child lines? If we recursively call loadLanguageFile from within loadLanguageFile when we encounter the parent_ini line, we might overwrite some strings that we don't want to. Solving item #1 above may work around this problem by pushing the @parent_ini line to the top of the file, but I'd rather fix it in a more foolproof way -- it may be necessary to split this into a two step process -- first create a stack of parsed language files, then merge them together in the correct order.
3.) As discussed on the mailing list, it would be nice to have a default fallback language. Perhaps this could be specified as a constructor parameter on the ExtendedIni class and passed in from a config.ini setting (fallback_language in [General], perhaps?) via the factory in module.config.php. Then if the filename passed to load() is not already the fallback language, we could load the fallback language prior to loading the main file.
I'll be happy to spend time on any or all of these items if you don't wish to work on them yourself. Just let me know if you have any different thoughts on any of these things, and which part or parts you would like to work on... then I'll act accordingly.
1.) A prefix is a good idea.
2.) Yes, if you don't put the parent_ini key in the top. We could also make it
@include = another.ini
That would change the semantics a bit and maybe make it clear that the included file would be handled at the position it is in the language file. I'm thinking that this could also be used e.g. to split a language file into "defaults" and local (overriding) changes.
3.) I'm ok with that, and I'll happily let you handle that one.
I agree that @include might describe the current functionality better than @parent_ini, but I think I prefer implementing a true parent function to having an include feature -- I can't think of a strong use case for having a position-dependent include feature, and this seems more likely to cause confusion than anything else. As far as local overriding changes go, this is already supported through the local/languages directory, so it seems better to stick with that than to change the architecture.
In any case, I'll see if I can find time to put together a new version of this functionality inspired by your PR but with some of the changes discussed above. Hopefully later this week!
Okay, I have reimplemented this with the new features discussed above. I decided not to add a fallback_language setting to config.ini, instead simply using the default language as the fallback value -- I can't think of a likely scenario where a user would want to configure a different fallback language from their primary language, and if they wanted to, it's an easily added feature... but for now, we might as well avoid unnecessary configuration bloat.