Re: [PATCH proxmox-yew-comp/widget-toolkit v3 0/4] i18n: add Greek and Irish translations

[Dominik Csapak <d.csapak@proxmox.com>]

On 6/22/26 2:15 PM, Maximiliano Sandoval wrote:
> Dominik Csapak <d.csapak@proxmox.com> writes:
> 
>> On 6/22/26 1:48 PM, Maximiliano Sandoval wrote:
>>> Dominik Csapak <d.csapak@proxmox.com> writes:
>>>
>>>> just a question, is it really necessary to import extjs weirdness into
>>>> our yew components? couldn't we simply use 'el' for greek (as
>>>> it's the right iso code and fits with the rest?)  we might need
>>>> to export both (at least for as long we have extjs uis).
>>> If desired, we could add back the patch for extjs adding `el` (just
>>> copying the files for the el_GR locale) as a new locale. I am not
>>> familiar enough with the differences between greek in Greece and in
>>> Cyprus (or if there are more greek speaking countries) to comment on
>>> whether this is a good idea.
>>
>> what i meant was in i18n we could export both 'el' (for yew) and 'el_GR' (for
>> extjs), wouldn't that be possible?
>>
> 
> I am not sure I follow.
> 
> One thing we could do is to present `el_GR` simply as "Greek" instead of
> "Greek (Greece)". The code can be treated as an implementation detail
> for now.

we use the iso code in yew to load the language file meaning
we have to package the language correctly for it to load.

if we'd package the i18n package such that it delivers an 'el' as well
as an 'el_GR' catalog, we can keep using el_GR for extjs based uis,
and 'el' for yew based guis.

> 
>>> Also note that gettext does not use iso codes for languages, but rather
>>> {iso_code}_{country_code}, so el_GR is fine [1].
>>> [1] https://www.gnu.org/software/gettext/manual/html_node/Locale-Names.html
>>
>> can be fine, but i'd like to have it consistent in yew, currently this
>> is only done for languages that need it (pt_BR, zh_CN, etc.)
>>
>> In case of greek there is only one greek language (ancient greek is iso code
>> 'grc' [0])
> 
> The same language can have multiple "locale codes" for the purposes of
> gettext. There are platforms where en_GB (or es_MX) are translated
> differently than `en` (or `es`).

i know, that's why i said that for greek, theres AFAIK only one
translation thus we should keep using 'el' where possible.

> 
>> I just don't like to do such things "just because extjs does it"
> 
> for what it is worth, GNOME only has `el` code for Greek.
> 
> [1] https://l10n.gnome.org/languages/


exactly, i guess because there is just one translation necessary
for greek....

> 
>> Though if it's very hard to implement, it's fine, but then i'd like
>> to have that reason in the commit message ;)
>>
> 
> See https://git.proxmox.com/?p=extjs.git;a=commit;h=4f893504d8a8e135461ce94d50f261584f769c4e.

this is only tangential related.

the commit was about removing unnecessary translations that already
existed under a different "iso-code" which we can't easily control.
there it makes sense to use that.

In yew, we can control both sides, so it IMO does not make sense to
break our pattern there just because it fits better with extjs.

That said, if you diverge from our usual pattern, please include an
explanation in the commit message.

> 
>>>
>>>>
>>>> I don't really like to import cruft/quirks from extjs here, except if
>>> As above this is probably not a quirk.
>>> Since `el` only came up in previous versions (at the time I tough it was
>>> a extjs quirk) of the series and the code is valid, I did not consider
>>> it interesting enough to mention it here.
>>>
>>>> there is a hard technical reason, but i'm missing that. the commit messages are
>>>> rather short :(
>>>
>>
>> 0: https://en.wikipedia.org/wiki/List_of_ISO_639_language_codes
>