Description: Please add language teams: cmn, nan, hak, yue, lzh Steps to Reproduce: Choosing languages. Actual Results: Supporting only the macro-language "zh" which is treated as a single language. Expected Results: Supporting all of (at least main) sinitic languages which are treated as dialects. Reproducible: Always User Profile Reset: No Additional Info: as ISO 639-3: gan, hak, czh, cjy, wuu, cmn, mnp, cdo, nan, czo, cpx, lzh, hsn, yue as glibc: hak, cmn, nan, lzh, yue
Not clear as to intent of "Supporting". Simply adding language idents for the the zh dialects? Or, implementing l10n of the UI with translations via Pootle?
Currently Wei-Lun will work on cmn for the moment, and UI should be added on Pootle together with a UI entry.
(In reply to sophie from comment #2) > Currently Wei-Lun will work on cmn for the moment, and UI should be added on > Pootle together with a UI entry. I don't know much about ISO 639, but from what I see on Wikipedia, cmn is Chinese Mandarin which is basically what zh_CN is right now. Why do we need a separate UI language for it?
https://en.wikipedia.org/wiki/ISO_639_macrolanguage IMHO, "zh" is not a proper language name, which should be broken into various sinitic languages, though it's almost impossible.
(In reply to 趙惟倫 from comment #4) > IMHO, "zh" is not a proper language name, which should be broken into > various sinitic languages, though it's almost impossible. I think replacing both zh_CN and zh_TW UI language options with something start with "cmn_" is a worthy discussion. However, having both cmn and zh_CN as options is confusing and counter-productive. And I assume what Sophie said "added on Pootle together with a UI entry" means that.
While 'zh' is only a macrolanguage tag, replacing the zh-CN and zh-TW language tags technically is not a good idea. Both are established in most major office programs and supporting them is necessary for interoperability, spell-checking, locale attribution and so on. Introducing other language tags to differentiate is fine, if translations differ and result in different UIs and/or different attribution. For 'cmn' vs 'zh-CN' I do not see this is the case. However, we could add cmn-CN for zh-CN and cmn-TW for zh-TW aliases. This actually makes sense in case imported document content is attributed that way to have it map to supported language tags.
Eike Rathke committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/+/c4f9b1cae7e9400b9aa4bc085ee39371c3b67485%5E%21 Related: tdf#125404 alias cmn-CN to zh-CN, cmn-TW to zh-TW It will be available in 6.4.0. The patch should be included in the daily builds available at https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: https://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Created attachment 152715 [details] Proof of concept for translation in Yue machine-translated, unreviewed po-files in Yue language for libo_ui.
A polite ping to Eike Rathke: Is this bug fixed? if so, could you please close it as RESOLVED FIXED ? Otherwise, Could you please explain what's missing? Thanks
The code part aliasing the cmn-* language tags is done. If we want a translation for Yue in Weblate that's something different and not really code related. If so, I can add the language string to UI, we already have the yue-HK LangID 0x048E tag so nothing that wouldn't be supported already. If it needs yue-CN I can add that as well. We should then decide on which locale should be the default for 'yue'. For the other languages mentioned in the original description per comment 0 let's just proceed as usual, if translation is available in Weblate add a locale language tag and a UI resource string for the language/locale.
Created attachment 156234 [details] PoC for translation in cmn_TW/yue_HK experimental, machine-translated, unreviewed po-files for cmn_TW/yue_HK.
(In reply to 趙惟倫 from comment #11) > Created attachment 156234 [details] > PoC for translation in cmn_TW/yue_HK > > experimental, machine-translated, unreviewed po-files for cmn_TW/yue_HK. So are you willing to manage a translation team in Weblate for Yue language?
(In reply to sophie from comment #12) > So are you willing to manage a translation team in Weblate for Yue language? No, I'm not a Yue native speaker.
I'm unassigning this bug from me. I assigned it to me because of the core code technical part of adding new language/locale tags to the known languages list, but I'm not responsible for anything translation related. As no one seems to be willing to actually lead a Yue translation project this bug might be better closed for now. I leave that up to the successors.
@bluebat, if you need the files in Weblate to further translation process of the UI and help, please open an new bug specifying the locale.
(In reply to sophie from comment #15) > @bluebat, if you need the files in Weblate to further translation process of > the UI and help, please open an new bug specifying the locale. Does the file in https://dev-www.libreoffice.org/l10n/latest-pot/ include all strings to translate, or not?
(In reply to 趙惟倫 from comment #16) > (In reply to sophie from comment #15) > > @bluebat, if you need the files in Weblate to further translation process of > > the UI and help, please open an new bug specifying the locale. > > Does the file in https://dev-www.libreoffice.org/l10n/latest-pot/ include > all strings to translate, or not? yes