all lists on lists.proxmox.com
 help / color / mirror / Atom feed
From: Dominik Csapak <d.csapak@proxmox.com>
To: Fiona Ebner <f.ebner@proxmox.com>,
	Proxmox VE development discussion <pve-devel@lists.proxmox.com>,
	Maximiliano Sandoval <m.sandoval@proxmox.com>
Subject: Re: [pve-devel] [PATCH widget-toolkit] i18n: mark strings as translatable
Date: Wed, 6 Dec 2023 12:22:23 +0100	[thread overview]
Message-ID: <cee75cc1-1208-4219-85bb-33bc5b6f1a18@proxmox.com> (raw)
In-Reply-To: <2b8569d7-b774-457b-8eab-134392f3cc4c@proxmox.com>



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




  reply	other threads:[~2023-12-06 11:22 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-11-29 13:21 Maximiliano Sandoval
2023-12-06  9:46 ` Dominik Csapak
2023-12-06 10:21   ` Maximiliano Sandoval
2023-12-06 11:00     ` Dominik Csapak
2023-12-06 11:13       ` Maximiliano Sandoval
2023-12-06 11:19         ` Dominik Csapak
2023-12-06 11:20       ` Fiona Ebner
2023-12-06 11:22         ` Dominik Csapak [this message]
2023-12-06 14:04       ` Maximiliano Sandoval
2023-12-06 14:26         ` Dominik Csapak
2023-12-06 15:54           ` Thomas Lamprecht
2023-12-06 15:16         ` Dietmar Maurer

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=cee75cc1-1208-4219-85bb-33bc5b6f1a18@proxmox.com \
    --to=d.csapak@proxmox.com \
    --cc=f.ebner@proxmox.com \
    --cc=m.sandoval@proxmox.com \
    --cc=pve-devel@lists.proxmox.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.
Service provided by Proxmox Server Solutions GmbH | Privacy | Legal