Wikimedia Bugzilla is closed!

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.

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 [[:de:|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.

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.

I meant interlanguage links. Sorry for the confusion.

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).

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).

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]].