On 2013-04-24 12:30 AM, "Erik Moeller" erik@wikimedia.org wrote:
[..]
In a nutshell, is it time to make MW aware of multiple content languages in a single wiki?
That would be nice.
- There's no consistent method by which multiple language editions of
the same page are surfaced for selection by the use. Different wikis use different templates (often multiple variants and layouts in a single wiki), different positioning, different rules, etc., leading to inconsistent user experience. Consistency is offered by language headers generated by the Translate extension, but these are used for managing translations, while multilingual content existing in the same wiki may often not take the form of 1:1 translations.
Moreover, language headers have to be manually updated/maintained, consider the user-friendliness of something like the +/- link in the language header on a page like https://commons.wikimedia.org/wiki/Commons:Kooperationen which leads to:
https://commons.wikimedia.org/w/index.php?title=Template:Lang-Partnerships&a...
Chances are that a lot of people who'd have the ability to provide a version (not necessarily a translation) of the page in a given language will give up even on the process of doing so correctly.
- There's no consistent method by which page name conflicts (which
may often occur in similar languages) are resolved, and users have to manually disambiguate.
- There are basic UX issues in the language selection tools offered
today. For example, after changing the language on Commons to German, I will see the page I'm on (say English) with a German user interface, even if there's an actual German content version of the page available. This is because these language selection tools have no awareness of the existence of content in relevant languages.
This is not entirely true. View an image description page with a license. Change your user language. The license template changes. This is accomplished by one of the worst hacks imaginable but does "work".
Although the way that is accomplished is ugly beyond belief, from the backend prespective, varying a page by user language is not a big deal afaik.
The general selection of different versions of entire pages doesnt work this way as you noted.
Points 4 and 5 could maybe be solved in not that hard a fashion if we had info on what language a page (or revision?) Is in.
[..]
current approach. For third party users, the effort of replicating something like the semi-acceptable Commons or Meta user experience is pretty significant, as well, due to the large number of templates and local hacks employed.
Indeed.
[..]
Would it make sense to add a language property to pages, so it can be used to solve a lot of the above issues, and provide appropriate and consistent user experience built on them? (Keeping in mind that some pages would be multilingual and would need to be identified as such.) If so, this seems like a major architectural undertaking that should only be taken on as a partnership between domain experts (site and platform architecture, language engineering, Visual Editor/Parsoid, etc.).
I don't think that is that big a problem (other than perhaps dealing with the multilingual case). We already have the page lang support. Seems like mostly putting an interface on top and somewhere to store the info.
-bawolff