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