[xwiki-devs] [Brainstorming] Should we keep the current translation naming rules for class property translations?
Hi devs, Context: I had some quick discussion on this PR () and it led to discussing our current naming rule for class property translations. Right now our rule is: http://dev.xwiki.org/xwiki/bin/view/Community/L10N%20Conventions#HTranslatin... I.e. for example: Gardening.Code.GardeningScriptConfigurationClass_activeQueryScripts I see at least 2 problems with this: 1) Problem 1: It’s not consistent with how we name other translations (we use lowercase everywhere and the prefix is the module name, not the space name). For example: gardening.wiki.selectScripts=Sélectionnez les scripts de jardinage actifs gardening.wiki.startJob=Démarrer le jardinage gardening.wiki.start=Jardiner ! gardening.job.success=Terminé ! gardening.job.error=Une erreur est survenue, consultez les journaux pour plus d'information. Gardening.Code.GardeningScriptConfigurationClass_activeQueryScripts=Scripts de requête actifs 2) Problem 2: It’s fragile as it depends on the location of the class. BTW just realizing that we may have broken lots of translations (and still are) when we moved code pages under the Code space… Did we check that? FTR, the LT solves this by offering a translation prefix that can be specified by the dev. WDYT? Do you agree with the problems? Do you see any other problem? Do you have any solution to propose? Note: I’m not suggesting to change this right now but I’d like that we come to an agreement to what we’d like to have in the future. Thanks -Vincent
I would like to insist on the fact that it's not just just a rule, it's actually a syntax. Changing this syntax actually means supporting both syntaxes for retro compatibility reasons. Whatever the choice it must be something you can deduce from the class reference and property name some way. Another possibility is introducing a way to indicate a custom translation prefix in the class so that you can have refactoring proof and/or more consistent <custom prefix>_<propert name> translation key in your extension. But that won't change the default syntax. On Thu, May 17, 2018 at 2:09 PM, Vincent Massol <[email protected]> wrote:
Hi devs,
Context: I had some quick discussion on this PR () and it led to discussing our current naming rule for class property translations.
Right now our rule is: http://dev.xwiki.org/xwiki/bin/view/Community/L10N%20Conventions#HTranslatin...
I.e. for example: Gardening.Code.GardeningScriptConfigurationClass_activeQueryScripts
I see at least 2 problems with this:
1) Problem 1: It’s not consistent with how we name other translations (we use lowercase everywhere and the prefix is the module name, not the space name). For example:
gardening.wiki.selectScripts=Sélectionnez les scripts de jardinage actifs gardening.wiki.startJob=Démarrer le jardinage gardening.wiki.start=Jardiner ! gardening.job.success=Terminé ! gardening.job.error=Une erreur est survenue, consultez les journaux pour plus d'information. Gardening.Code.GardeningScriptConfigurationClass_activeQueryScripts=Scripts de requête actifs
2) Problem 2: It’s fragile as it depends on the location of the class.
BTW just realizing that we may have broken lots of translations (and still are) when we moved code pages under the Code space… Did we check that?
FTR, the LT solves this by offering a translation prefix that can be specified by the dev.
WDYT? Do you agree with the problems? Do you see any other problem? Do you have any solution to propose?
Note: I’m not suggesting to change this right now but I’d like that we come to an agreement to what we’d like to have in the future.
Thanks -Vincent
-- Thomas Mortagne
On 17 May 2018, at 14:23, Thomas Mortagne <[email protected]> wrote:
I would like to insist on the fact that it's not just just a rule, it's actually a syntax. Changing this syntax actually means supporting both syntaxes for retro compatibility reasons.
Definitely.
Whatever the choice it must be something you can deduce from the class reference and property name some way.
True. Same as the LT.
Another possibility is introducing a way to indicate a custom translation prefix in the class so that you can have refactoring proof and/or more consistent <custom prefix>_<propert name> translation key in your extension. But that won't change the default syntax.
Yes I agree. That’s what I mentioned in the first email, same as it’s done for the LT. Thanks -Vincent
On Thu, May 17, 2018 at 2:09 PM, Vincent Massol <[email protected]> wrote:
Hi devs,
Context: I had some quick discussion on this PR () and it led to discussing our current naming rule for class property translations.
Right now our rule is: http://dev.xwiki.org/xwiki/bin/view/Community/L10N%20Conventions#HTranslatin...
I.e. for example: Gardening.Code.GardeningScriptConfigurationClass_activeQueryScripts
I see at least 2 problems with this:
1) Problem 1: It’s not consistent with how we name other translations (we use lowercase everywhere and the prefix is the module name, not the space name). For example:
gardening.wiki.selectScripts=Sélectionnez les scripts de jardinage actifs gardening.wiki.startJob=Démarrer le jardinage gardening.wiki.start=Jardiner ! gardening.job.success=Terminé ! gardening.job.error=Une erreur est survenue, consultez les journaux pour plus d'information. Gardening.Code.GardeningScriptConfigurationClass_activeQueryScripts=Scripts de requête actifs
2) Problem 2: It’s fragile as it depends on the location of the class.
BTW just realizing that we may have broken lots of translations (and still are) when we moved code pages under the Code space… Did we check that?
FTR, the LT solves this by offering a translation prefix that can be specified by the dev.
WDYT? Do you agree with the problems? Do you see any other problem? Do you have any solution to propose?
Note: I’m not suggesting to change this right now but I’d like that we come to an agreement to what we’d like to have in the future.
Thanks -Vincent
-- Thomas Mortagne
participants (2)
-
Thomas Mortagne -
Vincent Massol