[xwiki-devs] [Brainstorming] Should we keep the current translation naming rules for class property translations?
17 May
2018
17 May
'18
2:09 p.m.
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#HTranslati…
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
17 May
17 May
2:23 p.m.
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 <vincent(a)massol.net> 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#HTranslati…
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
2:30 p.m.
On 17 May 2018, at 14:23, Thomas Mortagne
<thomas.mortagne(a)xwiki.com> 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 <vincent(a)massol.net> 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#HTranslati…
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
2314
days inactive
2314
days old
2 comments
2 participants
participants (2)
-
Thomas Mortagne -
Vincent Massol