[xwiki-devs] Provide translations in JAR extensions
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
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? 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
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.
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
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)? 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
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
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). 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
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
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
participants (4)
-
Denis Gervalle -
Marius Dumitru Florea -
Thomas Mortagne -
Vincent Massol