From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from firstgate.proxmox.com (firstgate.proxmox.com [IPv6:2a01:7e0:0:424::9]) by lore.proxmox.com (Postfix) with ESMTPS id 30E131FF153 for ; Mon, 22 Jun 2026 15:25:29 +0200 (CEST) Received: from firstgate.proxmox.com (localhost [127.0.0.1]) by firstgate.proxmox.com (Proxmox) with ESMTP id 32D95C81A; Mon, 22 Jun 2026 15:25:27 +0200 (CEST) Message-ID: Date: Mon, 22 Jun 2026 15:25:21 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Beta Subject: Re: [PATCH proxmox-yew-comp/widget-toolkit v3 0/4] i18n: add Greek and Irish translations To: Maximiliano Sandoval References: <20260622113303.348962-1-m.sandoval@proxmox.com> <077b9442-cf9b-4a57-902c-dd1b8bce6ce5@proxmox.com> <4dece4a3-9591-4b04-8665-f89fcf11ad39@proxmox.com> Content-Language: en-US From: Dominik Csapak In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Bm-Milter-Handled: 55990f41-d878-4baa-be0a-ee34c49e34d2 X-Bm-Transport-Timestamp: 1782134712162 X-SPAM-LEVEL: Spam detection results: 0 AWL 0.048 Adjusted score from AWL reputation of From: address BAYES_00 -1.9 Bayes spam probability is 0 to 1% DMARC_MISSING 0.1 Missing DMARC policy KAM_DMARC_STATUS 0.01 Test Rule for DKIM or SPF Failure with Strict Alignment KAM_SHORT 0.001 Use of a URL Shortener for very short URL SPF_HELO_NONE 0.001 SPF: HELO does not publish an SPF Record SPF_PASS -0.001 SPF: sender matches SPF record Message-ID-Hash: EGYPPC6QB3IPKUXB4SASJCQT53JCAJDE X-Message-ID-Hash: EGYPPC6QB3IPKUXB4SASJCQT53JCAJDE X-MailFrom: d.csapak@proxmox.com X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; loop; banned-address; emergency; member-moderation; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; digests; suspicious-header CC: pve-devel@lists.proxmox.com X-Mailman-Version: 3.3.10 Precedence: list List-Id: Proxmox VE development discussion List-Help: List-Owner: List-Post: List-Subscribe: List-Unsubscribe: On 6/22/26 2:15 PM, Maximiliano Sandoval wrote: > Dominik Csapak writes: > >> On 6/22/26 1:48 PM, Maximiliano Sandoval wrote: >>> Dominik Csapak 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 >