[pve-devel] [PATCH widget-toolkit] i18n: mark strings as translatable

[pve-devel] [PATCH widget-toolkit] i18n: mark strings as translatable

[Maximiliano Sandoval]

Note that ACME is already in 3 translatable strings, a similar remark
applies to N/A which is already translated in many languages.

Signed-off-by: Maximiliano Sandoval <m.sandoval@proxmox.com>
---
 src/node/DNSView.js                   | 2 +-
 src/panel/ACMEDomains.js              | 2 +-
 src/panel/DiskList.js                 | 6 +++---
 src/window/NotificationMatcherEdit.js | 2 +-
 4 files changed, 6 insertions(+), 6 deletions(-)

diff --git a/src/node/DNSView.js b/src/node/DNSView.js
index 4782f9c..d2a784f 100644
--- a/src/node/DNSView.js
+++ b/src/node/DNSView.js
@@ -21,7 +21,7 @@ Ext.define('Proxmox.node.DNSView', {
 	    run_editor: run_editor,
 	    rows: {
 		search: {
-		    header: 'Search domain',
+		    header: gettext('Search domain'),
 		    required: true,
 		    renderer: Ext.htmlEncode,
 		},
diff --git a/src/panel/ACMEDomains.js b/src/panel/ACMEDomains.js
index a7fb088..9e2e34b 100644
--- a/src/panel/ACMEDomains.js
+++ b/src/panel/ACMEDomains.js
@@ -10,7 +10,7 @@ Ext.define('Proxmox.panel.ACMEDomains', {
     mixins: ['Proxmox.Mixin.CBind'],
 
     margin: '10 0 0 0',
-    title: 'ACME',
+    title: gettext('ACME'),
 
     emptyText: gettext('No Domains configured'),
 
diff --git a/src/panel/DiskList.js b/src/panel/DiskList.js
index 4808f5c..dc10ac5 100644
--- a/src/panel/DiskList.js
+++ b/src/panel/DiskList.js
@@ -325,14 +325,14 @@ Ext.define('Proxmox.DiskList', {
 	    dataIndex: 'status',
 	},
 	{
-	    header: 'Mounted',
+	    header: gettext('Mounted'),
 	    width: 60,
 	    align: 'right',
 	    renderer: Proxmox.Utils.format_boolean,
 	    dataIndex: 'mounted',
 	},
 	{
-	    header: 'Wearout',
+	    header: gettext('Wearout'),
 	    width: 90,
 	    sortable: true,
 	    align: 'right',
@@ -341,7 +341,7 @@ Ext.define('Proxmox.DiskList', {
 		if (Ext.isNumeric(value)) {
 		    return (100 - value).toString() + '%';
 		}
-		return 'N/A';
+		return gettext('N/A');
 	    },
 	},
     ],
diff --git a/src/window/NotificationMatcherEdit.js b/src/window/NotificationMatcherEdit.js
index f88576a..e717ad7 100644
--- a/src/window/NotificationMatcherEdit.js
+++ b/src/window/NotificationMatcherEdit.js
@@ -1025,7 +1025,7 @@ Ext.define('Proxmox.panel.NotificationMatchRuleSettings', {
 	    ],
 	},
 	{
-	    fieldLabel: 'Match Type',
+	    fieldLabel: gettext('Match Type'),
 	    xtype: 'proxmoxKVComboBox',
 	    reference: 'type',
 	    isFormField: false,
-- 
2.39.2

Re: [pve-devel] [PATCH widget-toolkit] i18n: mark strings as translatable

[Dominik Csapak]

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

rest looks fine to me though

On 11/29/23 14:21, Maximiliano Sandoval wrote:
> Note that ACME is already in 3 translatable strings, a similar remark
> applies to N/A which is already translated in many languages.
> 
> Signed-off-by: Maximiliano Sandoval <m.sandoval@proxmox.com>
> ---
>   src/node/DNSView.js                   | 2 +-
>   src/panel/ACMEDomains.js              | 2 +-
>   src/panel/DiskList.js                 | 6 +++---
>   src/window/NotificationMatcherEdit.js | 2 +-
>   4 files changed, 6 insertions(+), 6 deletions(-)
> 
> diff --git a/src/node/DNSView.js b/src/node/DNSView.js
> index 4782f9c..d2a784f 100644
> --- a/src/node/DNSView.js
> +++ b/src/node/DNSView.js
> @@ -21,7 +21,7 @@ Ext.define('Proxmox.node.DNSView', {
>   	    run_editor: run_editor,
>   	    rows: {
>   		search: {
> -		    header: 'Search domain',
> +		    header: gettext('Search domain'),
>   		    required: true,
>   		    renderer: Ext.htmlEncode,
>   		},
> diff --git a/src/panel/ACMEDomains.js b/src/panel/ACMEDomains.js
> index a7fb088..9e2e34b 100644
> --- a/src/panel/ACMEDomains.js
> +++ b/src/panel/ACMEDomains.js
> @@ -10,7 +10,7 @@ Ext.define('Proxmox.panel.ACMEDomains', {
>       mixins: ['Proxmox.Mixin.CBind'],
>   
>       margin: '10 0 0 0',
> -    title: 'ACME',
> +    title: gettext('ACME'),
>   
>       emptyText: gettext('No Domains configured'),
>   
> diff --git a/src/panel/DiskList.js b/src/panel/DiskList.js
> index 4808f5c..dc10ac5 100644
> --- a/src/panel/DiskList.js
> +++ b/src/panel/DiskList.js
> @@ -325,14 +325,14 @@ Ext.define('Proxmox.DiskList', {
>   	    dataIndex: 'status',
>   	},
>   	{
> -	    header: 'Mounted',
> +	    header: gettext('Mounted'),
>   	    width: 60,
>   	    align: 'right',
>   	    renderer: Proxmox.Utils.format_boolean,
>   	    dataIndex: 'mounted',
>   	},
>   	{
> -	    header: 'Wearout',
> +	    header: gettext('Wearout'),
>   	    width: 90,
>   	    sortable: true,
>   	    align: 'right',
> @@ -341,7 +341,7 @@ Ext.define('Proxmox.DiskList', {
>   		if (Ext.isNumeric(value)) {
>   		    return (100 - value).toString() + '%';
>   		}
> -		return 'N/A';
> +		return gettext('N/A');
>   	    },
>   	},
>       ],
> diff --git a/src/window/NotificationMatcherEdit.js b/src/window/NotificationMatcherEdit.js
> index f88576a..e717ad7 100644
> --- a/src/window/NotificationMatcherEdit.js
> +++ b/src/window/NotificationMatcherEdit.js
> @@ -1025,7 +1025,7 @@ Ext.define('Proxmox.panel.NotificationMatchRuleSettings', {
>   	    ],
>   	},
>   	{
> -	    fieldLabel: 'Match Type',
> +	    fieldLabel: gettext('Match Type'),
>   	    xtype: 'proxmoxKVComboBox',
>   	    reference: 'type',
>   	    isFormField: false,

Re: [pve-devel] [PATCH widget-toolkit] i18n: mark strings as translatable

[Maximiliano Sandoval]

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"

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.

While there are no examples of this specifically for "ACME", there is a
similar one:

"ACL" is a translatable string which appears in two other translations

    #: proxmox-widget-toolkit/src/window/AuthEditLDAP.js:361
    #: proxmox-widget-toolkit/src/window/SyncWindow.js:110
    #: pve-manager/www/manager6/dc/AuthEditLDAP.js:333
    #: pve-manager/www/manager6/dc/RealmSyncJob.js:355
    #: pve-manager/www/manager6/dc/SyncWindow.js:129
    msgid "ACL"
    msgstr ""

There are at least two languages that actually translate it:

ru:
    msgid "ACL"
    msgstr "Список управления доступом"

ar:
    msgid "ACL"
    msgstr "قائمة التحكم في الوصول"

Both translation make use of this in other translations, as shown in the
following translations:

ru:
   msgid "Remove ACLs of vanished users and groups."
   msgstr "Удалить списки управления доступом исчезнувших пользователей и групп."

ar:
   msgid "Remove ACLs of vanished users and groups."
   msgstr "إزالة قوائم التحكم بالوصول للمستخدمين والمجموعات المختفية."

I personally lean towards not translating it, but in my option, that is
a decision that belongs to the translator, having the string be
translatable gives them more context to make this choice.

All of this would be simpler if we could extract comments with xgettext
to signal that certain parts of strings should ideally not be
translated.

Of course, if this is polemic enough, it could be separated into a
different commit/mail-discussion.

--
Maximiliano

Re: [pve-devel] [PATCH widget-toolkit] i18n: mark strings as translatable

[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...

> 
> While there are no examples of this specifically for "ACME", there is a
> similar one:
> 
> "ACL" is a translatable string which appears in two other translations
> 
>      #: proxmox-widget-toolkit/src/window/AuthEditLDAP.js:361
>      #: proxmox-widget-toolkit/src/window/SyncWindow.js:110
>      #: pve-manager/www/manager6/dc/AuthEditLDAP.js:333
>      #: pve-manager/www/manager6/dc/RealmSyncJob.js:355
>      #: pve-manager/www/manager6/dc/SyncWindow.js:129
>      msgid "ACL"
>      msgstr ""
> 
> There are at least two languages that actually translate it:
> 
> ru:
>      msgid "ACL"
>      msgstr "Список управления доступом"
> 
> ar:
>      msgid "ACL"
>      msgstr "قائمة التحكم في الوصول"
> 
> Both translation make use of this in other translations, as shown in the
> following translations:
> 
> ru:
>     msgid "Remove ACLs of vanished users and groups."
>     msgstr "Удалить списки управления доступом исчезнувших пользователей и групп."
> 
> ar:
>     msgid "Remove ACLs of vanished users and groups."
>     msgstr "إزالة قوائم التحكم بالوصول للمستخدمين والمجموعات المختفية."

i'd argue that this is different since we use ACL not as a name,
but as an abbreviation that might not make sense in other languages
(though maybe even that shouldn't be translated...)

it's more like DHCP, SLAAC or IPv4. those are names of protocols (like 
ACME) that shouldn't change across translations

and we removed those gettexts (mostly) a while ago
e.g. see lxc/Network.js in pve-manager:

---8<---
boxLabel: 'DHCP', // do not localize
--->8---

> 
> I personally lean towards not translating it, but in my option, that is
> a decision that belongs to the translator, having the string be
> translatable gives them more context to make this choice.

again, we generally don't translate names (dhcp, slaac, ceph, ....) and
ACME is just one of these names

> 
> All of this would be simpler if we could extract comments with xgettext
> to signal that certain parts of strings should ideally not be
> translated.
> 
> Of course, if this is polemic enough, it could be separated into a
> different commit/mail-discussion.
> 
> --
> Maximiliano

Re: [pve-devel] [PATCH widget-toolkit] i18n: mark strings as translatable

[Maximiliano Sandoval]

Dominik Csapak <d.csapak@proxmox.com> writes:

> the translator must make sure the terms are consistent anyway...

This is the heart of the issue. The translator cannot know there are
more uses of the string if it is not marked as translatable.

--
Maximiliano

Re: [pve-devel] [PATCH widget-toolkit] i18n: mark strings as translatable

[Dominik Csapak]

On 12/6/23 12:13, Maximiliano Sandoval wrote:
> 
> Dominik Csapak <d.csapak@proxmox.com> writes:
> 
>> the translator must make sure the terms are consistent anyway...
> 
> This is the heart of the issue. The translator cannot know there are
> more uses of the string if it is not marked as translatable.

yes he can, because he shouldn't be translating these strings
in a vacuum. I'd expect a minimum of cross checking the gui
and familiarity with the product/gui.

we don't give the translation files to people that have
never seen/used the pve/pbs/pmg interfaces, rather
it's users that want to use it in their own
language. If they don't know what the name/phrase/etc.
means or show up in the gui context, that's a problem
in general and leads to weird translations either way.

As an example: if i wanted to translate 'ACME'
without context and know nothing about proxmox products,
i might just put 'GIPFEL' for german
(the literal translation of the english word 'acme' in all caps...)
like google translate would suggest

> 
> --
> Maximiliano

Re: [pve-devel] [PATCH widget-toolkit] i18n: mark strings as translatable

[Fiona Ebner]

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

Re: [pve-devel] [PATCH widget-toolkit] i18n: mark strings as translatable

[Dominik Csapak]

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

Re: [pve-devel] [PATCH widget-toolkit] i18n: mark strings as translatable

[Maximiliano Sandoval]

Dominik Csapak <d.csapak@proxmox.com> writes:

> it's more like DHCP, SLAAC or IPv4. those are names of protocols (like ACME)
> that shouldn't change across translations
>
> and we removed those gettexts (mostly) a while ago
> e.g. see lxc/Network.js in pve-manager:
>
> ---8<---
> boxLabel: 'DHCP', // do not localize
> --->8---

Do note the following examples:

    #: pve-manager/www/manager6/qemu/IPConfigEdit.js:97
    #: pve-manager/www/manager6/qemu/IPConfigEdit.js:155
    msgid "DHCP"
    msgstr "بروتوكول التهيئة الآلية للمضيفين (DHCP)"

    #: pve-manager/www/manager6/qemu/IPConfigEdit.js:163
    msgid "SLAAC"
    msgstr "Autoconfiguration SLAAC"

    #: pve-manager/www/manager6/ceph/CephInstallWizard.js:476
    msgid "First Ceph monitor"
    msgstr "أول جهاز مراقبة"

What would be the purpose of removing the translation of the words
themselves if they are already being translated elsewhere.

--
Maximiliano

Re: [pve-devel] [PATCH widget-toolkit] i18n: mark strings as translatable

[Dominik Csapak]

On 12/6/23 15:04, Maximiliano Sandoval wrote:
> Dominik Csapak <d.csapak@proxmox.com> writes:
> 
>> it's more like DHCP, SLAAC or IPv4. those are names of protocols (like ACME)
>> that shouldn't change across translations
>>
>> and we removed those gettexts (mostly) a while ago
>> e.g. see lxc/Network.js in pve-manager:
>>
>> ---8<---
>> boxLabel: 'DHCP', // do not localize
>> --->8---
> 
> Do note the following examples:


yeah i said we didn't remove all of those instances
and it seems there are some not so good translations still existing.
(bad translations are not a good argument for translating even
more of them? I'd argue they are even an argument that we should
reduce them)


> 
>      #: pve-manager/www/manager6/qemu/IPConfigEdit.js:97
>      #: pve-manager/www/manager6/qemu/IPConfigEdit.js:155
>      msgid "DHCP"
>      msgstr "بروتوكول التهيئة الآلية للمضيفين (DHCP)"

Does not really make sense IMO to translate this, since
DHCP already is an established abbreviation and there
is no need to write it out localized.

> 
>      #: pve-manager/www/manager6/qemu/IPConfigEdit.js:163
>      msgid "SLAAC"
>      msgstr "Autoconfiguration SLAAC"

IMHO this makes even less sense, SLAAC
already includes 'autoconfiguration', so why do this?

> 
>      #: pve-manager/www/manager6/ceph/CephInstallWizard.js:476
>      msgid "First Ceph monitor"
>      msgstr "أول جهاز مراقبة"

doesn't mention ceph in the translation at all....
(which it should!)

> 
> What would be the purpose of removing the translation of the words
> themselves if they are already being translated elsewhere.

none of the examples here translate the words in a meaningful manner,
should be either already known, mentioned in the docs, or be
easily searchable online.
also it only causes issues when using an overly long text
in a field label

> 

> --
> Maximiliano

honestly i don't want to argue/bikeshed about such a small detail,
but i don't see a good reason to translate names and established
(technical) words.

I'm ready to change my mind, but i did not see a good example
of when it would be good to translate 'ACME' (or DHCP, Ceph, etc.)
into something different yet.

Re: [pve-devel] [PATCH widget-toolkit] i18n: mark strings as translatable

[Thomas Lamprecht]

Am 06/12/2023 um 15:26 schrieb Dominik Csapak:
> honestly i don't want to argue/bikeshed about such a small detail,
> but i don't see a good reason to translate names and established
> (technical) words.
> 
> I'm ready to change my mind, but i did not see a good example
> of when it would be good to translate 'ACME' (or DHCP, Ceph, etc.)
> into something different yet.

+1

Re: [pve-devel] [PATCH widget-toolkit] i18n: mark strings as translatable

[Dietmar Maurer]

> Do note the following examples:
> 
>     #: pve-manager/www/manager6/qemu/IPConfigEdit.js:97
>     #: pve-manager/www/manager6/qemu/IPConfigEdit.js:155
>     msgid "DHCP"
>     msgstr "بروتوكول التهيئة الآلية للمضيفين (DHCP)"
> 
>     #: pve-manager/www/manager6/qemu/IPConfigEdit.js:163
>     msgid "SLAAC"
>     msgstr "Autoconfiguration SLAAC"
> 
>     #: pve-manager/www/manager6/ceph/CephInstallWizard.js:476
>     msgid "First Ceph monitor"
>     msgstr "أول جهاز مراقبة"
> 
> What would be the purpose of removing the translation of the words
> themselves if they are already being translated elsewhere.

IMHO all those are terribly wrong. I would remove them immediately.