public inbox for pve-devel@lists.proxmox.com
 help / color / mirror / Atom feed
From: Thomas Lamprecht <t.lamprecht@proxmox.com>
To: Maximiliano Sandoval <m.sandoval@proxmox.com>
Cc: PVE development discussion <pve-devel@pve.proxmox.com>
Subject: Re: [pve-devel] [PATCH manager v2] fix #4634: ui: osd: allow to translate the entire string
Date: Tue, 5 Sep 2023 08:37:47 +0200	[thread overview]
Message-ID: <f529626e-c11f-476a-b8af-8f2a2057b094@proxmox.com> (raw)
In-Reply-To: <06fd86b4-0bf0-4dcf-a611-8ed936f4b1a2@proxmox.com>

CC'ing the mailing list again.

Am 05/09/2023 um 08:01 schrieb Maximiliano Sandoval:
> On 9/4/23 18:26, Thomas Lamprecht wrote:
>> Am 28/08/2023 um 17:54 schrieb Maximiliano Sandoval:
>>> -    title: Ext.String.format(gettext('Manage {0}'), 'Global OSD Flags'),
>>> +    // TRANSLATORS: This will read 'Manage Global OSD Flags'.
>>> +    title: Ext.String.format(gettext('Manage Global {0} Flags'), 'OSD'),
>> Hmm, not sure how often this will be reused where {0} will be replaced with
>> something else. I'd rather prefer one of:
>>
>> - Ext.String.format(gettext('Manage {0}'), gettext('Global OSD Flags')),
>>    "Manage XYZ" is relatively common, so we might have more reuse potential.
>>
>> - gettext('Manage Global OSD Flags')
>>    Fine too, as IMO this is rather specific anyway and unlikely that we have
>>    many others where a parametrized msgstr is really reducing translation
>>    effort.
>>
>> what do you think?
>
> I don't think that re-usability should very high in the priority list when it comes
> to translations, the first example for example could potentially make a
> satisfactory translation to certain languages impossible.

Re-usability sure is important for us, one shouldn't have to bend backwards just
for that, like it felt you did with the "'Manage Global {0} Flags'), 'OSD'" one,
but certainly good to use a harmonised set of terminology.

FWIW: avoiding to much churn is definitively also high on the priority list, as
that doesn't makes life of translators easier.

> 
> I don't see any problem with the second suggested approach, which as it happens
> is the contents of v1 of the patch.
> 

Yeah, I'd rather like the full thing here, as said it's specialized enough to not
bother with re-usability here until we'd actual require it (maybe if there are
global monitor or MDS flags), as future-proofing for translations is especially
hard. That would then also allow us to drop the comment due it becoming superfluous.

ps. Please don't top post, that's making this harder and rather irritating to read
and follow.




      parent reply	other threads:[~2023-09-05  6:38 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-08-28 15:54 Maximiliano Sandoval
2023-09-04 16:26 ` Thomas Lamprecht
     [not found]   ` <06fd86b4-0bf0-4dcf-a611-8ed936f4b1a2@proxmox.com>
2023-09-05  6:37     ` Thomas Lamprecht [this message]

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=f529626e-c11f-476a-b8af-8f2a2057b094@proxmox.com \
    --to=t.lamprecht@proxmox.com \
    --cc=m.sandoval@proxmox.com \
    --cc=pve-devel@pve.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
Service provided by Proxmox Server Solutions GmbH | Privacy | Legal