My only comment is that I don't like too much naming a resource file with an uppercase as the first letter. AFAIK it's a known best practice to use lowercase in java and (and most if not all our other resources files are named with lowercases: logback.xml, all our js files, all our css files, etc). But I understand the rationale about having the same name as we currently have for oldcore… We could ask for lowercase and fall back to uppercase if not found for backward compatibilty. Not a big deal, just thought I would mention it. Thanks -Vincent On Dec 19, 2012, at 1:51 PM, Thomas Mortagne <[email protected]> wrote:
Hi devs,
The last piece missing to the new localization framework for 4.x is to allow providing translations in a jar extension.
Here are some ideas:
1) Continue with ApplicationResources_*.properties files but loads it from everywhere instead of taking the first one we find like now 2) Same that 1) but place it somewhere a bit "cleaner" like org/xwiki/localization/translation_*.properties 3) Completely different system. I looked a bit if any simple de facto standard was already existing but was not obvious.
Keep in mind the localization framework allow providing any source so it's easy to move/add a new way to get translations in jar extensions later without touching the API so while it would be better to do something good it's mostly implementation details and whatever we choose we are not going to be stuck with it forever.
WDYT ?
I would go for 2) (I'm +0 for 1)) with org/xwiki/localization/translation_*.properties for 4.x and keep 3) for later when we have some time to work on it a bit more.
-- Thomas Mortagne