[pve-devel] [PATCH widget-toolkit] i18n: mark strings as translatable
Dominik Csapak
d.csapak at proxmox.com
Wed Dec 6 12:22:23 CET 2023
On 12/6/23 12:20, Fiona Ebner wrote:
> Am 06.12.23 um 12:00 schrieb Dominik Csapak:
>> On 12/6/23 11:21, Maximiliano Sandoval wrote:
>>>
>>> Dominik Csapak <d.csapak at proxmox.com> writes:
>>>
>>>> translating ACME does not make sense to me since it's
>>>> the name of the protocol and stands for
>>>> Automatic Certificate Management Environment
>>>>
>>>> i don't think/believe this should be translated
>>>> into other languages as a standalone word
>>>
>>> "ACME" appears in four translatable strings, e.g.
>>>
>>> msgid "ACME Accounts"
>>
>> which makes sense since 'accounts' must be translated
>>
>>>
>>> Having the term itself being translatable allows the translator to be
>>> consistent on which term to use when there are multiple translatable
>>> strings containing it. It would be confusing for the user if the only
>>> place where they see "ACME" is in the original string.
>>
>> but that does not change whether ACME is translatable or not.
>> In one case we just 'force' the translator to use it like we intended
>>
>> the translator must make sure the terms are consistent anyway...
>>
>
> We could switch to template strings to actively prevent ACME from being
> translated in such instances, i.e. "{0} Accounts". Note that this does
> not take away much flexibility from the translator, because the position
> of {0} is not fixed in the translation ;)
while i agree with the sentiment, this is not always a good idea.
in some languages the word would change depending on what '{0}' is
in these situations i think having more context would be better
when translating
More information about the pve-devel
mailing list