[Brainstorming] Should we keep the current translation naming rules for class property translations?

classic Classic list List threaded Threaded
3 messages Options
Reply | Threaded
Open this post in threaded view
|

[Brainstorming] Should we keep the current translation naming rules for class property translations?

vmassol
Administrator
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
Reply | Threaded
Open this post in threaded view
|

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

Thomas Mortagne
Administrator
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 <[hidden email]> 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 | Threaded
Open this post in threaded view
|

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

vmassol
Administrator


> On 17 May 2018, at 14:23, Thomas Mortagne <[hidden email]> 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 <[hidden email]> 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