[pve-devel] [PATCH pve-widget-toolkit] Changed 'kr' to 'ko' in language list

[pve-devel] [PATCH pve-widget-toolkit] Changed 'kr' to 'ko' in language list

[Noel Ullreich]

the ISO 639-1 two letter abbreviation of Korean is 'ko', not 'kr'

Signed-off-by: Noel Ullreich <n.ullreich@proxmox.com>
---
kr is apparently Kanuri, a language spoken in Nigeria, Niger, Chad, and
Cameroon.

 src/Utils.js | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/src/Utils.js b/src/Utils.js
index 34c348f..5e1a6f3 100644
--- a/src/Utils.js
+++ b/src/Utils.js
@@ -75,7 +75,7 @@ utilities: {
 	he: `עברית - ${gettext("Hebrew")}`,
 	it: `Italiano - ${gettext("Italian")}`,
 	ja: `日本語 - ${gettext("Japanese")}`,
-	kr: `한국어 - ${gettext("Korean")}`,
+	ko: `한국어 - ${gettext("Korean")}`,
 	nb: `Bokmål - ${gettext("Norwegian (Bokmal)")}`,
 	nl: `Nederlands - ${gettext("Dutch")}`,
 	nn: `Nynorsk - ${gettext("Norwegian (Nynorsk)")}`,
-- 
2.30.2

Re: [pve-devel] [PATCH pve-widget-toolkit] Changed 'kr' to 'ko' in language list

[Thomas Lamprecht]

Am 24/03/2023 um 15:41 schrieb Noel Ullreich:
> the ISO 639-1 two letter abbreviation of Korean is 'ko', not 'kr'
> 

great find, but without renaming the PO file this breaks the whole translation
completely, which isn't ideal for users - as for them the underlying used two
letter code was just an invisible implementation detail.

So I'd do the rename there, but that then needs to handle the update
transition.

In widget-toolkit we do not depend on any i18n package as widget-toolkit is
also used in more than one project; adding an OR'd `pve-i18n | pmg-i18n |
pbs-i18n` could work but is a bit of a PITA as some tools will use the first
one here (e.g.  debootstrap) if one isn't careful.  So, we could instead add a
virtual proxmox-widget-toolkit-i18n package that all pmg/pve/pbs- i18n ones
provide as $binary:version and make proxmox-widget-toolkit depend on that;
would be IMO slightly cleaner.

Independent from what will be used to track the dependency from wtk to i18n, we
would need to break older widget-toolkit in newer i18n and depend on newer i18n
(via or'd or virtual) in newer widget toolkit; that is if we straight do the
move.

But, that'd not solve the setups out there with users having kr in the
PVELangCookie (or PBS/PMG) already set.

For that we'd need to either ship also a symlink for the previously used kr.po,
plus some code stanza that checks the cookie and sets it to `ko` if it is `kr`,
which can then be removed someday, maybe trixie. Otherwise we could simply
translate this in the http servers back to ko, but not much of a point in
renaming it now then.

anyway & tldr; we learn that renaming translation files can bring a lot of
required churn to ensure backward compatibility. Would be easier to just
mention that this is using the ISO 3166 Alpha 2 for south korea and that
changing it is rather hard and a not so great ROI, so we keep it until we
actually get a translation (request) for the language that ISO 639-1 `kr`
refers to. So, correctness aside, this would be waaay faster and have less
breakage potential ¯\_(ツ)_/¯

Re: [pve-devel] [PATCH pve-widget-toolkit] Changed 'kr' to 'ko' in language list

[Fabian Grünbichler]

> Thomas Lamprecht <t.lamprecht@proxmox.com> hat am 26.03.2023 16:51 CEST geschrieben:
> 
> In widget-toolkit we do not depend on any i18n package as widget-toolkit is
> also used in more than one project; adding an OR'd `pve-i18n | pmg-i18n |
> pbs-i18n` could work but is a bit of a PITA as some tools will use the first
> one here (e.g.  debootstrap) if one isn't careful.  So, we could instead add a
> virtual proxmox-widget-toolkit-i18n package that all pmg/pve/pbs- i18n ones
> provide as $binary:version and make proxmox-widget-toolkit depend on that;
> would be IMO slightly cleaner.

IIRC having just a Depends: on a virtually-provided package provided by more than one actual package is even worse with regards to tooling support (hence the Debian policy of always depending on "actual-package | virtual-package", like "initramfs-tools (>= 0.120+deb8u2) | linux-initramfs-tool", or "uniquely-provided-virtual-package | virtual-package", like "default-mta | mail-transport-agent" to express a preference, and the corresponding behaviour in debootstrap and buildd to only look at the first arm of an ORed dependency).

Also, Provides/virtual packages are not really a good fit for this problem, since the packages don't provide the same thing and proxmox-widget-toolkit also cannot use them interchangeably (i.e., on PVE having pmg-i18n installed is a nop and doesn't help at all, but it would satisfy the dependency).

I think in this case the solution would be to add Breaks to both/all involved packages for the old version (so that no combination of new+old can be installed) and add bumped versioned dependencies higher up the stack (e.g., pve-manager) to force the upgrade - if we want to have this transition, that is ;)

Re: [pve-devel] [PATCH pve-widget-toolkit] Changed 'kr' to 'ko' in language list

[Thomas Lamprecht]

Am 27/03/2023 um 09:58 schrieb Fabian Grünbichler:
> 
>> Thomas Lamprecht <t.lamprecht@proxmox.com> hat am 26.03.2023 16:51 CEST geschrieben:
>>
>> In widget-toolkit we do not depend on any i18n package as widget-toolkit is
>> also used in more than one project; adding an OR'd `pve-i18n | pmg-i18n |
>> pbs-i18n` could work but is a bit of a PITA as some tools will use the first
>> one here (e.g.  debootstrap) if one isn't careful.  So, we could instead add a
>> virtual proxmox-widget-toolkit-i18n package that all pmg/pve/pbs- i18n ones
>> provide as $binary:version and make proxmox-widget-toolkit depend on that;
>> would be IMO slightly cleaner.
> 
> IIRC having just a Depends: on a virtually-provided package provided by more than one actual package is even worse with regards to tooling support (hence the Debian policy of always depending on "actual-package | virtual-package", like "initramfs-tools (>= 0.120+deb8u2) | linux-initramfs-tool", or "uniquely-provided-virtual-package | virtual-package", like "default-mta | mail-transport-agent" to express a preference, and the corresponding behaviour in debootstrap and buildd to only look at the first arm of an ORed dependency).

hmm, scratch the virtual package; we could really produce the package including
translations for widget-toolkit hosted translations though.

Actually it could be move to a dev dependency that every package using gettext
depends on and will use to produce the respective filtered out translation list
for their code, that way we could easier re-use it on other non-JavaScript UI's
too; but certainly a bigger change.

> 
> Also, Provides/virtual packages are not really a good fit for this problem, since the packages don't provide the same thing and proxmox-widget-toolkit also cannot use them interchangeably (i.e., on PVE having pmg-i18n installed is a nop and doesn't help at all, but it would satisfy the dependency).
> 

that's not true, *all* packages (as they are now) satisfy the translation
requirements from *proxmox-widget-toolkit*, and pmg-gui would then have the
more explicit dependency on pmg-i18n anyway.

> I think in this case the solution would be to add Breaks to both/all involved packages for the old version (so that no combination of new+old can be installed) and add bumped versioned dependencies higher up the stack (e.g., pve-manager) to force the upgrade - if we want to have this transition, that is ;)
>
Yeah, that's certainly a solution as mentioned, but I'd rather look at this
in the next major release; maybe rework packaging a bit to make it a better
fit for the depending packages.

Re: [pve-devel] [PATCH pve-widget-toolkit] Changed 'kr' to 'ko' in language list

[Fabian Grünbichler]

> Thomas Lamprecht <t.lamprecht@proxmox.com> hat am 27.03.2023 10:15 CEST geschrieben:
> Am 27/03/2023 um 09:58 schrieb Fabian Grünbichler:
> > 
> >> Thomas Lamprecht <t.lamprecht@proxmox.com> hat am 26.03.2023 16:51 CEST geschrieben:
> > Also, Provides/virtual packages are not really a good fit for this problem, since the packages don't provide the same thing and proxmox-widget-toolkit also cannot use them interchangeably (i.e., on PVE having pmg-i18n installed is a nop and doesn't help at all, but it would satisfy the dependency).
> > 
> 
> that's not true, *all* packages (as they are now) satisfy the translation
> requirements from *proxmox-widget-toolkit*, and pmg-gui would then have the
> more explicit dependency on pmg-i18n anyway.

fair enough - missed that part :)