Author: rd232
Description:
It is essential to support the multingualism of Wikimedia Commons (especially for categories) to allow page titles to be translated. T7638 attempted to do this by building on interlanguage links. T7638#101531 there is given as the reason for T7638 being repeatedly WONTFIXed. If those issues are indeed insurmountable then ANOTHER SOLUTION MUST BE FOUND. (Sorry for shouting, but this message didn't get through at the tail of the T7638 discussion.) Thank you.
See Also:
| Status | Subtype | Assigned | Task | ||
|---|---|---|---|---|---|
| Open | None | T31928 Show translated titles per user language in categories too | |||
| Open | Feature | None | T31975 Provide a way to alter page titles in category listings, e.g. via display title | ||
| Duplicate | None | T19212 Use {{DISPLAYTITLE}} as link label on category pages | |||
| Resolved | None | T22278 Cache DISPLAYTITLE to use it in categories and for tooltips | |||
| Declined | None | T55945 A cheap way to get information from page_props table for all links on page (similar to LinkCache?) needed | |||
| Open | Feature | None | T24586 Allow (optional) displaying of sort key rather than (full)page names for category items | ||
| Open | Feature | None | T350648 Show redirects in categories with suffix, not italics. |
EN.WP.ST47 wrote:
This is an i18n bug (or possibly user interface), not a parser one. How do you suggest that translated titles be input? This could be done with JS (I know I have a userscript on enwiki that colors titles based on their article grade) or using iwlinks (shot down because article titles can contain other stuff - disambig, etc. - and not all articles exist crosslanguage) or using some new way of encoding it in the page text (woo, a more bloated parser) or using some new way of encoding it in the database (woo, a schema change and new special page and permission). Something to consider is whether it is sufficient for a page title to be displayed in the user's language or whether it must also be searchable/linkable.
rd232 wrote:
iwlinks made a certain sense to me, with an option to override the iwlink for the title if necessary (eg [[:de:Foo]] would use Foo for the German title, [[:de:Foo (bar)|Foo2]] would use Foo2, and [[🇩🇪|Foo3]] would use Foo3, for the case where no target interwiki exists). However, it occurs to me that while this would work fine for page titles for the page the user is on, I'm not sure how it would work for page titles when looking at a category listing - which is an important aspect of the issue. I don't know a solution!
In an answer to your question, I'd certainly settle for page title being displayed in the user's language; but searchable/linkable would be helpful.
EN.WP.ST47 wrote:
We actually mean langlinks, not iwlinks. iwlinks is inline links to other wikis, which could be to entirely unrelated pages, langlinks is the left sidebar's list. langlinks has the advantage of being indexed by language, so here's basically how that would happen.
If a wiki has translate titles enabled ($wgTranslateTitles or something), then somewhere in Title.php we could probably do a lookup against the langlinks table, perhaps based on "select ll_title from langlinks where ll_from = $this->mArticleID and ll_lang = $wgLang->getCode();".
That's the simple easy way, at least. that doesn't require a schema change or parser hacks. If the interlanguage links were going to have a new format, like [[de:Page (disambig)|Page]], we could have a new column in the langlinks for the translated title, and the parser would need to handle a new syntax or two.
Of course, none of this takes into account allowing these titles to be used in search or urls. I don't know one bit about how search works, but if URLs were going to support it there would need to be some sort of conflict resolution between multiple pages with the same translatedtitle either in the same or different languages.
And of course, if you actually meant iwlinks (using [[:de:stuff|otherstuff]] instead of [[de:stuff|otherstuff]]) then I'd be interested in hearing justification for that, but I don't really think it would work.
As it stands (With existing software support) we could do this in a _very_ hacky way by setting $wgRestrictDisplayTitle = false; and then using the int: hack for different translations with {{DISPLAYTITLE}}. However, then someone could create a title that doesn't go to the relevant page which would be confusing. Perhaps an option to allow display titles that redirect to the current page (less strict than the restrictDisplayTitle, but still pretty strict).
test5555 wrote:
For Commons, this probably only makes sense in Category namespace.
It might be easier to just display a subtitle in the user's language from interwikis.
The translate extension can do this already, but it can't solve bug 29975 (which seems to be a dependency, not a blocker).
ForoaW wrote:
The current langlink could just be displayed next to the category or gallery name. Hovering over language links could show a window of the first paragraph of the concerned article.
Wikidata might help here. See [[d:Wikidata:Wikimedia Commons]] and [[commons:User:Kozuch/Wikidata]].
Maybe Structured Data on Wikimedia Commons could implement this. @Keegan_(WMF) , is this possible?
I don't know how to tag or ping people here, if someone could ping someone from the Structured Data on Wikimedia Commons project that would be great.
@DonTrung: Use https://www.mediawiki.org/wiki/Talk:Phabricator/Help for discussing Phab itself. Thanks.
Just letting you know I got your ping, but I won't be able to look into this task this week as I'm out of office.
I guess structured data would eventually make categories useless anyway, but perhaps this can at least be implemented as a script that people can use. I think the main issue though is not so much the display, but rather the possibility to input category names in languages other than English and Binomial Latin. I constantly encounter en-0 Ukrainians attempting to use Ukrainian category names, for example, and some on the fly conversion would be helpful even if it would require enabling a script.