Moving discussion from MediaWiki.org to Phabricator.

Design decision made. Follow-up in T323111: Include icons for vertical writing modes .

Looks like we need both writing directions, but we could still use the rotated direction by default for vertical writing and set to unrotated when we need the Han-character-upright direction.

We need to determine/"fix" the design to prevent squished menus on Vector 2022 mobile/narrow screen.

In T286291#11418700, @Winston_Sung wrote:

The only remaining patch(es) should be the magic word part, which is still a work in progress/to-do.

https://gerrit.wikimedia.org/r/c/mediawiki/core/+/879987

The only remaining patch(es) should be the magic word part, which is still a work in progress/to-do.

T31272: Implement Gadgets 2.0 , T31272#9574686 .

However, should I still proceed with my patch to ensure they have the exact same height for semantic consistency, or is the current state acceptable?

(Although they still don't have the same height, they now under the same background-color element.)

I would believe this was caused by https://gerrit.wikimedia.org/r/c/887855 and got fixed in https://gerrit.wikimedia.org/r/c/897906 .

It appears that it's no longer a problem in both Vector 2010 and Vector 2022:

We would like to bring language-data to MediaWiki core.

1. Questions
   1. Should we move this repository to Gerrit/GitLab?

Reason for Gerrit:

• We could easily make the list of users with CR +2 rights the same with mediawiki/core on Gerrit.
• It would be hard for integration of Depends-On on different platforms. (There's no CI injection/dependency feature for libraries in Wikimedia Gerrit.)

Reason for GitLab: Contributors aren't required to accept third party privacy policies.

The reason it should be under Gerrit instead of GitLab is due to the decision of the project layout.

This repository shold fall under mediawiki/libs (i.e., named as mediawiki/libs/LanguageData and included in /vendor in mediawiki/core) as it should contain PHP codes, and all mediawiki/libs/ projects were on Gerrit while none of them were on GitLab.

• Wikimedia Gerrit - All of them
• Wikimedia GitLab - No /libs

https://www.mediawiki.org/wiki/GitLab/Migration_status

Should composer.json be exported?

Looks like we need composer.json to be exported, should it be removed from .gitattributes export-ignore?

https://gerrit.wikimedia.org/r/c/mediawiki/vendor/+/1056254

Nikki wrote:

The language-data format doesn't support all the data they have (multiple scripts, Wikidata IDs, English names, parent language/families, etc), and requires data that is hard to get (autonyms), I think it would need big changes if it's ever going to be useful for things other than selecting a MediaWiki interface language.

1. Considerations
   • BCP 47 Language/script/region/variant subtags
   • ISO codes
     • NOTE: This is actually different from BCP 47 subtags.
   • MediaWiki internal language codes
   • Wikidata IDs
   • WikiLambda ZID
   • Autonyms (language name written in its local writing system)
   • The script in which a language is written
     • Multiple scripts
   • The regions in which the language is spoken/written
   • Translations of language names
     • English names
   • Language fallback chains
   • Parent language/families
   • The writing mode of the text
     • The directionality of the text
     • The writing-mode property of the text
   • Time formats

https://github.com/wikimedia/language-data/issues/372

Yeah. I know that.

Solution 2 seems to be better.

Problem
Hard to find/monitor non-Mandarin Sinitic languages wiki tasks

NOTE: Please do NOT use this tag for tasks that about non-Mandarin Chinese languages/dialects (Cantonese yue , Mindong cdo , Minnan nan , Wu wuu , ...) and Literary Chinese lzh , unless if they are also affecting sites that mentioned below. Also, please do not add this tag for issues about /zh pages on multilingual sites (Meta-Wiki, Commons, Wikidata, etc.). Such issues are parts of MediaWiki-extensions-Translate interface issues, and should always be handled in that project.

NOTE: Please do NOT use this tag for tasks that about non-Mandarin Chinese languages/dialects (Cantonese yue , Mindong cdo , Minnan nan , Wu wuu , ...) and Literary Chinese lzh , unless if they are also affecting sites that mentioned below. Also, please do not add this tag for issues about /zh pages on multilingual sites (Meta-Wiki, Commons, Wikidata, etc.). Such issues are parts of MediaWiki-extensions-Translate interface issues, and should always be handled in that project.

NOTE: Please do NOT use this tag for tasks that about non-Mandarin Chinese languages/dialects (Cantonese yue , Mindong cdo , Minnan nan , Wu wuu , ...) and Literary Chinese lzh , unless if they are also affecting sites that mentioned below. Also, please do not add this tag for issues about /zh pages on multilingual sites (Meta-Wiki, Commons, Wikidata, etc.). Such issues are parts of MediaWiki-extensions-Translate interface issues, and should always be handled in that project.

Appears to be lowercase:

@Allenwang6212a for confirmation.

Just discovered it should be all lowercase.

Both on page 4 of the PDF files (but one of the footer labeled as 3).

In Formosan languages, the language autonym usually be the same word of "people"/"human" in the language, so:

@srishakatux

Maybe it's time to get rid of language-converter-only namespace display names.

Yeah, the fix didn't work as it used the wrong Language object.

In T392749#11193458, @Amire80 wrote:

As to the fallback logic of the user interface, Proveit currently checks for messages in the preferred user language variant, and if that fails, it fallbacks to English. Can this be improved? Should Proveit fallback to 'zh' if 'zh-cn' is not available? Or to 'zh-hans'? Or to the main content language of the wiki? Or is English ok?

(removed for better reading order)

There was never zh-cn.json and should always use zh-hans.json instead.

Please check the following URLs instead:

The MessagesZh namespace names are intended to be in English to use them as the canonical namespace name in URL, prevent lean to one of the language variants and prevent technical issues related to the zh language converter.

There's also a TranslateVariants user script/gadget to acheieve the similar feature:

I would suggest implement the pretranslate-by-convert feature to Translate extension, something similar to Wikibase:

Without using /zh-hans, /zh-hant, /zh-hk, we have to pass the language tag every time.

We would actually need pages to be able exist in multiple sort keys at the same time (e.g., "章" has 2 defined radicals "音" and "立" ) to completely get the feature work.

https://codelookup.toolforge.org/sh use the action=query&meta=languagestats&lslanguage=sh Action API.