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 <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:
> I.e. for example:
> 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
> 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.