On Thu, Dec 20, 2012 at 8:49 AM, Denis Gervalle <[email protected]> wrote:
On Wed, Dec 19, 2012 at 3:12 PM, Thomas Mortagne <[email protected]>wrote:
On Wed, Dec 19, 2012 at 3:02 PM, Marius Dumitru Florea < [email protected]> wrote:
On Wed, Dec 19, 2012 at 2: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
+1 for looking for ApplicationResources_*.properties in the root of the jar, thus +1 for putting ApplicationResources_*.properties in src/main/resources, as it is now in oldcore.
2) Same that 1) but place it somewhere a bit "cleaner" like org/xwiki/localization/translation_*.properties
Do you think 1) can lead to "conflicts", i.e. loading ApplicationResources_*.properties that were not intended for the localization module?
It's just that I don't like to have all the translation files mixed with other stuff and find nicer to have them in their own folder.
Is there any other reason to not do 1) ? Since 1) also include 2), we may have a convention for 2) and an implementation for 1).
The implementation in 1) and 2) is exactly the same, the only difference is an arbitrary choice of where to put those files.
WDYT ?
Thanks, Marius
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 _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
-- Thomas Mortagne _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
-- Denis Gervalle SOFTEC sa - CEO eGuilde sarl - CTO _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
-- Thomas Mortagne