> On 17 May 2018, at 14:23, Thomas Mortagne <thomas.morta...@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.


> 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.


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

Reply via email to