Re: [xwiki-devs] [Brainstorming] Should we keep the current translation naming rules for class property translations?

[Vincent Massol]

> On 17 May 2018, at 14:23, Thomas Mortagne  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 _ 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  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#HTranslatingXClasses
>> 
>> 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

Re: [xwiki-devs] [Brainstorming] Should we keep the current translation naming rules for class property translations?

[Thomas Mortagne]

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 _ translation key
in your extension. But that won't change the default syntax.

On Thu, May 17, 2018 at 2:09 PM, Vincent Massol  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#HTranslatingXClasses
>
> 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