all lists on lists.proxmox.com
 help / color / mirror / Atom feed
From: Fiona Ebner <f.ebner@proxmox.com>
To: Proxmox VE development discussion <pve-devel@lists.proxmox.com>,
	Dominik Csapak <d.csapak@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:20:16 +0100	[thread overview]
Message-ID: <2b8569d7-b774-457b-8eab-134392f3cc4c@proxmox.com> (raw)
In-Reply-To: <97caa32b-eb4d-434e-965c-b65d51761a41@proxmox.com>

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 ;)




  parent reply	other threads:[~2023-12-06 11:20 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 [this message]
2023-12-06 11:22         ` Dominik Csapak
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=2b8569d7-b774-457b-8eab-134392f3cc4c@proxmox.com \
    --to=f.ebner@proxmox.com \
    --cc=d.csapak@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