On Wed, Dec 19, 2012 at 11:15 PM, Marius Dumitru Florea < [email protected]> wrote:
> On Wed, Dec 19, 2012 at 4: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. > > I'm fine with 2) but does it mean we'll have to migrate > ApplicationResources_*.properties files from oldcore (to > org/xwiki/localization/translation_*.properties)? > That's not a big deal, I'm not planning to remove the retro-compatibility support for ApplicationResources too soon. But if you don't feel it's important feel free to vote for 1). As I said I'm not against it, I just feel 2) is cleaner and since the implementation will change anyway it's not more work than 1) > > Thanks, > Marius > > > > > > >> > >> 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 > _______________________________________________ > 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
