Last modified: 2014-09-08 16:48:13 UTC
The header "This page is a translated version of..." should be at the bottom of the page by default and not at the top. It gets too much in the way for reading. One option would be to place it next (above/below) "This page was last modified on..." since it's the same type of information. Should I open a new request?
CCing Pau. We discussed this request a bit at Wikimania. Some thoughts after that: * Pau said that the information in this header could be merged with the information offered by the <languages /> bar. The idea is to concentrate all the info about translations in the same place. Makes sense to me. * Following on that idea, the <languages /> bar could be automatically added to pages translatable/translated (now it's a manual task). It makes sense to say that admins want to show that bar always in those pages. * After several weeks playing with my pet project I'm pretty sure that such information should be better placed at the bottom of the page. At the top it just disrupts the reading all the time. The language selector at the top of the page and the new "Translate" tab already suggest that this is a multilingual site. * Other possibility is to just emulate Wikipedia's interwiki links at the left column. Almost anywhere is better than the current location between the title and the first paragraph (although I understand why for historical reasons it was placed there initially).
Changing the bug subject to define the problem instead of proposing a specific solution.
After thinking a bit more... Couldn't this be solved by simply replicating the well tested UI of Wikipedia: all languages available listed in the Sidebar. The "Translate this page" link would be at the end of the list of languages, following the same style of the current "Edit links" in Wikipedia. The icon with the % of completion could be droppe. It is more interesting for translators than for users, but translators have already a full fledged reports. About the messages on the translated pages, they could be shown as a banner only when there is a problem with the translation (incomplete, outdated or both), encouraging the user to fix it. In those cases it would be fine to have them at the top as they are now. If the translation is 100% and up to date then there would be no banner to show. The current "Translate" tab is enough advertising.
In the mean time this patch could be added to Mobile.js [1] to optimise this for mobile (on mobile the languages take up all the screen meaning you have to scroll to get to any content - this could be very offputing to developers!) [1] https://gist.github.com/jdlrobson/6355928
Including the <languages /> bar by default, and somehow integrating it with the "This page is a translated version of..." message sound like reasonable ideas. However, I fail to see what is so horrible about listing the available translations on top; at least for the desktop version. This seems to be a pretty standard practice elsewhere, such as on http://blog.flickr.net/ or on Global Voices, one of the most advanced and successful multilingual blogging platforms (see e.g. http://globalvoicesonline.org/2013/08/26/wikipedia-in-guarani/ , they even list the translated title in addition to the language name for each translation). It's also the approach we are taking in the redesigned version of the Wikimedia blog that is going to launch soon, using a version of the WPML multilingual Wordpress plugin. (Admittedly I can't dispute the above statement that the current layout "disrupts the reading all the time" on the bug submitter's "pet project" because I don't know what that pet project is.) And the purpose of that language list is not to "suggest that this is a multilingual site" in some vague sense, but specifically to inform the reader about the availability or non-availability of translations in particular languages for the page they are looking at.
As said in my previous comment, Wikipedia made popular the language links in the left column and that seems to work well. Why not applying the same principle in the Translate extension, for the benefit of multilingual MediaWikis? It is a consistent and well tested solution. It probably would fix the mobile view in one go, since MobileFrontend knows how to handle those language links. PS: my pet project is http://espiral.org
For someone who doesn't speak multiple languages listing the languages at the top is rather frustrating (especially on mobile) I think the key thing is there should be a consistent way of displaying languages. Currently in the Vector skin languages appear in the left hand navigation menu. We should be consistent and treat these language links the same. It is terrible user experience to have 2 places for what effectively in result are the same thing. The mobile site is currently extremely broken as a result of this inconsistency. You have to scroll before you can view any content - fine on a touch phone but not so fine on an older device where scrolling is slow...
(In reply to comment #7) > For someone who doesn't speak multiple languages Well, this is the situation for most people visiting those pages. Even if you do speak 2-3 languages, the chances of finding your exact combination at sight is rather slim. I think the current design is made by translators for translators, which is fine for a start and for certain specific sites, but not for your average multilingual site. I just wonder: considering that MediaWiki & MobileFrontend already contain the code to display language links in the left column (at the bottom in mobile), would it be difficult to just use this functionality?
Note this bug blocks adding the https://m.mediawiki.org/wiki/How_to_contribute?debug=true page to the footer of the mobile site.
(In reply to comment #7) > For someone who doesn't speak multiple languages listing the languages at the > top is rather frustrating (especially on mobile) Actually I'm not sure I fully understand - isn't that language list already collapsed at the bottom in the mobile view, at least for pages on Meta that use the Translate extension? (e.g. https://meta.m.wikimedia.org/wiki/Wikimedia_Highlights,_July_2013 - btw, it's very problematic that the list behind that "Read in another language" button lists all initiated translations without indication about their completion status, even when they are only 2% complete. Currently only 4 of the 35 language versions listed there are fully complete). This bug was originally only about the "This page is a translated version of..." sentence on top. > > I think the key thing is there should be a consistent way of displaying > languages. Currently in the Vector skin languages appear in the left hand > navigation menu. We should be consistent and treat these language links the > same. It is terrible user experience to have 2 places for what effectively in > result are the same thing. They are not the same thing. The interwiki links in the left sidebar link to pages about the same topic in other projects, which in most cases contain very different text (it's a common misconception that different language Wikipedias are just translations of each other - they're not). The language list on top however customarily links to translations of the same text - "customarily" in the sense that it's handled like this in the Translate extension, in the old translation system on Meta (i.e. the usual position of https://meta.wikimedia.org/wiki/Template:Other_languages ), on Global Voices, on the Flickr blog, and also on Commons, another multilingual Wikimedia project. On Commons you can actually see both kinds of links used on the same page, separated by position: https://commons.wikimedia.org/wiki/Category:Drawings (the left sidebar links to categories about the same topic with different content, the box on top links to translated, identical descriptions of the same category with the same content). > > The mobile site is currently extremely broken as a result of this > inconsistency. You have to scroll before you can view any content - fine on a > touch phone but not so fine on an older device where scrolling is slow... Again, that's not the case on my S3 where the "This page is a translated version of..." message takes up only one sixth of the screen for https://meta.m.wikimedia.org/wiki/Wikimedia_Highlights,_July_2013 . We appear to be talking about different things.
(In reply to comment #10) > This bug was originally only about the "This page is a translated version > of..." sentence on top. True, but the discussion has evolved to include the rest of translation elements under the title. I have edited the topic accordingly. But I agree it is good to keep discussing desktop only here, otherwise the topic becomes too broad. > They are not the same thing. The interwiki links in the left sidebar link to > pages about the same topic in other projects, which in most cases contain > very different text. Yes, we know this. However, the message is the same: if you prefer (your language) to (the language you are reading) then click here. > On Commons you can actually see both kinds of links used on the same page, > separated by position: https://commons.wikimedia.org/wiki/Category:Drawings Thank you, I was trying to find a page with that combination. The main point about this page is that the big blue box taking the most prominent space is quite intrusive and of little use for most readers landing on a page like that. The list of languages in the left column have a header that reads "In Wikipedia". For these corner cases you could still have the other languages by default in the left column and then append at the end the "In (somewhere else)" section.
Ah, sorry. In fact the list of languages at https://commons.wikimedia.org/wiki/Category:Drawings doesn't even correspond to the page but to the banner alone. This is a matter of the design of that banner, so I wouldn't include it in this discussion.
> > I think the key thing is there should be a consistent way of displaying > > languages. Currently in the Vector skin languages appear in the left hand > > navigation menu. We should be consistent and treat these language links the > > same. It is terrible user experience to have 2 places for what effectively in > > result are the same thing. > > They are not the same thing. I understand this but you must also understand that this is naturally how a reader will interpret both of these things - same content, different language. I don't think we should conflate the two.. At the very least the HTML markup for both languages should be similar and they should be styled similar - they should both identify themselves as list of languages with consistent meta data to be able to determine the type of language.
Ok, let me go back to the initial point of this report: Translation information under the page title is too obtrusive It could be placed at the end of the article, without any other changes, and the main problem of this report would be solved. I guess this is a simple implementation? This use case is akin to the famous Wikipedia banner "This article is a stub. You can help expanding it." It makes sense to show the call to action "Translate this page" to those reaching that point, allowing a good reading flow to everybody.
After a short conversation with Pau, we agree that there are multiple problems here: * The links to existing translations and the call to translators should be part of the same object. We need a design for this. Pau has a draft (where?). * The current text could be shortened, or even limited to a minimal but meaningful expression. There is already a tab for "Translate", there is already a link to "English", there is already an indicator of completion. * The list of languages visible by default could be shortened, see [[mw:User:Niharika/Compacted_Interlanguage_Links_as_a_beta_feature]] (co-mentored by Pau) * The position of that object in the page is unclear. I proposed under the sidebar, since this is where interwiki links sit now in Wikipedia et al. Maybe a new location is proposed in the future? Even if it would stay near the title, it could be aligned to the right (left in RTL), not to be so much in the way like now. In any case, I would propose to place it wherever interwikis are located for consistency, but I'm happy with any better solution. As a side effect, this solution would avoid the fact of having to add <languages /> manually to pages. Is there a reason to have translations of a page and not wiling to offer links to those translations? Is there a bug report about this open already?
Created attachment 14651 [details] Possible design Some design options to integrate the list of languages and the translation action. Progress indicators for each language are lacking in the design but can be added.
What about a compact (default?) version simply showing... In the original language pages: [百] | Add + (no translations) [百] | French | Add + (only one translation is available) [百] | 2 more | Add + (more translations available) ([百] == a "languages" icon) In a translated page (assuming English is the original): English | Add + (only this translation is available) English | Français | Add + (another translation available) English | 2 more | Add + (more translations available) Potential portrait mode: [百] 2 more Add + English Français Add + Do you want to see more languages by default? A preference could be defined to set those: English | Afrikaans | العربية | asturianu | بلوچی مکرانی | български | Add + English Afrikaans العربية asturianu بلوچی مکرانی български Add + I don't have a strong opinion about the completion indicators either. If needed they can be added. This would simplify all the messages being shown currently: * "Translate this page", there is a "Translate" tab, and now we would get the "Add +" * "This page is a translated version of a page Happiness for everyone", solved with "English" linking to the original page. * "and the translation is 43% complete.", non-relevant? The % is quite arbitrary, and if the translation is incomplete it shouldn't take much to a reader to notice. We can add a % somewhere if needed. * "This page has changes since it was last marked for translation.", is this a message useful for anybody else than those with the permissions to mark pages for translation? Could be saved to everybody else, the problem is in the translated pages, not in this one.
Hey, I would like to take up the redesign of language bar under my GSoC project. Please review https://www.mediawiki.org/wiki/User:Kunalgrover05/GSoc_Proposal#Redesign_of_interface_on_pages_and_language_bar
Change 149585 had a related patch set uploaded by Kunalgrover05: Language bar first design(in progress) https://gerrit.wikimedia.org/r/149585
The current Winter prototype at http://unicorn.wmflabs.org/winter/ is proposing an expandable language box at the top right column. I like it a lot. What about using that design and that position of the page, just adding a "Translate" link integrated with that box?
(In reply to Quim Gil from comment #20) There is no right column in any of existing skins.
Sure, but it is still possible to align an element to the top right area of an article. This is where Kunal is trying to locate the langage box anywaym according to the mockups he has shared at https://gerrit.wikimedia.org/r/149585 : https://commons.wikimedia.org/wiki/File:Language_bar_default.png I'm just suggesting to use Winter's design instead of trying to squeeze the current wide language box design in a place where it needs to be narrow.
I'm not opposed, but we need to take into account non-JavaScript look (not present in the mockups) as well as do testing how well this works in different skins and on different pages. If it causes problems we might need to give users some flexibility on the placement and shape. We should also use ULS for showing the full list to not reinvent the wheel.
Created attachment 16369 [details] ECB language selection The other attachment is quite similar to the ecb.eu main page language selectors. Is there a gallery of existing solutions adopted around the web (or even just in the europa.eu domain: there might be no other relevant comparison considering that even coe.int, un.int and osce.org look quite English-centric)?
GSoC ended, this feature is not implemented, and I hope Kunal will stick around until completing it...
Kunal: Would be awesome if you could share your plans here. If you think that you (realistically) have time to continue working on this, feel free to set yourself as assignee.
I am still willing to work on this. The latest patch fixed the Low and medium priority bugs pointed by Pau. The first implementation is pretty much ready and can be merged after review.
