When I choose Hindi / Kannada / Tamil on commons.wikimedia.org and try to upload a file - the information templates are in English and there are no license choices available in the dropdown.
Description
Related Objects
Event Timeline
Commons does not track non-code issues, such as l10n, on Phabricator. Please bring one of the following on-wiki discussion pages:
- https://commons.wikimedia.org/wiki/Commons:Help_desk
- https://commons.wikimedia.org/wiki/Commons:Village_pump
- https://commons.wikimedia.org/wiki/Commons:Translators%27_noticeboard
- https://commons.wikimedia.org/wiki/Commons:Administrators%27_noticeboard (only if clear-cut instructions on how to fix this problem is available and require admin action)
Amir Aharoni mentioned in a personal discussion that this needs some server side fixes.
Asking @Amire80 to elaborate as per last comment (same for T184863: Commons Localization - Kannada Language)
So we have 3 issues here:
the information templates are in English
The template wikitext are not localized for obvious reasons:
- Method 1: make the {{Information}} template support the i18n:
- The template would need a fallback list of every single parameter for every single language ({{{lang1|{{{lang2|{{{lang3|{{{....|}}}}}}}}}. This will:
- Make the parsing itself much slower. Just consider the number of parameter expansions needed just to if the parameter happens to be the last language in the fallback list...
- Make the template unmaintainable. Nobody's gonna read through thousands of curly braces.
- Make the fallback list editable by only admins. Yeah, you wouldn't want a random person to edit a page and break millions of pages, do you?
- Every single language will need a redirect to the template. This probably isn't too bad, but:
- Most of them would get protected to admin-only due to being widely used template.
- The template would need a fallback list of every single parameter for every single language ({{{lang1|{{{lang2|{{{lang3|{{{....|}}}}}}}}}. This will:
- Method 2: Or, we could make a lot of dummy templates, eg: Template:OtherLangTemplate would be something like {{Information|description={{{otherlangparam|}}}}}. Would may make the load and short-term maintainability better, but:
- Yeah, all of these templates would get protected.
- And, what if we in the future decide to add a parameter to {{Information}}? Are we supposed to update every single dummy template? Who's going to notify the translators?
- Seriously, are we doing i18n for only {{Information}}? What about infobox templates like {{Artwork}}, {{Book}}, {{Photograph}}? Or even other widely-used infobox-like templates such as {{Creator}}, {{Institution}}? Are we gonna spent a long time making all of these i18n-supported?
- What about bots that parse these pages? Are they required to somehow figure out which template and parameter is the one they are looking for?
- And finally and most importantly, if the wikitext are localized to the language of the uploader, how are editors of other languages supposed to understand and edit them? Remember, when editing, wikitexts of one language can't magically change to another language.
So no, we are not going to make wikitext itself localized unless proper support is built in into MediaWiki, in which case please file a bug under MediaWiki-Parser & MediaWiki-Internationalization. Besides, we have MediaWiki:UploadForm.js and UploadWizard to make the upload process internationalized (the former may or may not; I have it disabled so I do not know).
no license choices available in the dropdown
MediaWiki:Licenses has not been translated to every single language. I do not know why it does not fallback to the English version, which you can file a bug under MediaWiki-Special-pages and/or MediaWiki-Uploading and/or MediaWiki-Internationalization. For translation to your language, please submit an {{edit request}} on the corresponding talk pages of the language subpages, with the exact text you want the translation page be.
link to the wizard based upload does not show when one choose the file upload link on the left panel
I cannot reproduce this. MediaWiki:Gadget-UploadWizard.js should always replace that sidebar link to UploadWizard after the page fully loads. If not, this would be a JavaScript error and please report to the above mentioned on-wiki discussion pages with the information as required by the previous link.
Per above, I decided to reopen this task.
@zhuyifei1999 I'm afraid this can only resolvable via submitting a normal patch aganist rEUWI, there haven't anything we can do just on Commons locally
Of the three issues I've listed, which one do you refer to by 'this'?
submitting a normal patch aganist rEUWI
Why do you think UW has anything to do with this task, according to T184863#3899377? This task is regarding the issues of the upload forms, not UW. Besides, as said, the third issue, the only part relevant to UW, is not reproduceable without further information. In any case, please split this task into specific errors that can be resolved individually; 'generic tasks' like 'improve Commons l10n' are not resolveable at all.
@zhuyifei1999 but then how do you explain those untranslated parts in that screenshot that you provided?
- "Browse..." button
- No file selected.
- dropdown box which says "Standard"
- Categories (+)
Both implemented by browser. A sane browser should translate the text internally according to the browser language settings. Yes it may possible to override it using some JS input overhaul like OOJS-UI, but to do so when the browser already does the i18n is reinventing the wheel.
- dropdown box which says "Standard"
MediaWiki:Edittools explicitly stated against translation for a very good reason. If you feel that the benefit of having a translation outweigh the costs, see T184862#3899174.
- Categories (+)
MediaWiki:Gadget-HotCat.js line 79. Translations welcome.
In any case, none of these are bugs of MediaWiki core or its extensions.
