FANDOM


  • My proposal concerns the {{Languages}} template, that link box for articles that lists documentation i18n. I suspect that the template has a large number of accessibility issues:

    • Positioned within the content, away from other navigational elements
    • Overly prominent in mobile, with potentially obtrusive positioning across platforms
    • Presence of text separators (|) - these can trip screen readers and don't offer good portability
    • High link density and lack of touch friendliness

    Of course, removing it entirely would be a horrible option and wouldn't be nice to translators. I18n is a great thing for this wiki, and the goal should be to support it.

    So my proposal is that we use a interwiki dropdown instead. Staff have set up an interlanguage map with KockaAdmiralac's help, which you can test on our mainpage. This system's totally compatible with the old one thanks to Kocka's work in Module:Languages.

    We did float alternatives like the wiki using the infobox navigation tag (instead of the interwiki feature). But we thought this was best. Opinions for/against and alternatives are welcome.

      Loading editor
    • One concern I raised was that after the link change the pages will start appearing in Special:LonelyPages after links get migrated to interlanguage links. One way to solve this will be linking them from List of JavaScript enhancements / List of CSS enhancements, but these already need some kind of automation. Additionally, translations of guides like Installation couldn't be inserted there.

        Loading editor
    • does the dropdown offer english language? i don't see a way to get the /en subpage: https://snag.gy/9wK2Ig.jpg

        Loading editor
    • This seems like a good idea for readers but as an editor, I'd find this a lot slower than the current template. I like to see all the translations of a page without having to hover over a relatively out-of-site dropdown menu. Could we find some sort of in-between solution?

        Loading editor
    • I think the Wikimedia Foundation solved that by having an interwiki search & modal feature that can list all the options. Should I add something similar in LangSelectEdit?

        Loading editor
    • As en is a no-go, those subpages will get merged into their parent document pages. This ensures a good fallback and makes the template tags unnecessary in documentation pages. Parsing will be finnicky but should be okay.

        Loading editor
    • So we aren't going to do LangSelect transclusions like we've been doing of late (e.g. BotManagement)? I'm not really sure what you mean.

        Loading editor
    • We'd do {{{parameter|en string}}} in base page. Then override it with LangSelect & transclusion in the i18n subpage. Bit of a U-turn from the last Discord conversation on it, but I guess this change necessitates it. 😛

        Loading editor
    • Makes sense. I don't really understand your response to my concern about the better functionality of the Languages template for desktop though.

        Loading editor
    • Something like this: https://vignette.wikia.nocookie.net/speedit/images/2/23/Languages_modal.png/revision/latest?cb=20181018102113&format=original

      Launched by selecting this: https://vignette.wikia.nocookie.net/speedit/images/4/44/Languages_search.png/revision/latest?cb=20181018102717&format=original

      You can see something similar by visiting Wikipedia articles on desktop. They have an interlanguage button that launches a search filter.

        Loading editor
    • I was thinking about doing interwiki prefixes pointing back to Dev, but I never got around to testing it.

      One minor issue I have with this is to do with the lang dropdown in general. It's a pain to scroll to a language, and the most frequently needed one you set in your prefs :) Search option is nice, but something simple like moving wgUserLanguage to the top would be even more handy (though I have that in my global.js anyway ;))

        Loading editor
    • dropdown might have userlanguage and en as 1st and 2nd entries in the list. it would reduce scrolling pain.

        Loading editor
    • Thank you for updating the template (^-^)

      As you said, surely the interlanguage links take height so much today (and honestly I don’t like the present situation). But as an editor and non-English user, I don’t want to scroll down dropdown lists and don’t want to scroll down pages to see interlanguage links. I didn’t think dropdown list of languages at community centrals were bad, but Developers wiki has lots of languages to scroll down... (And I think language names list is better than flag navigation)

      In addition, I would like to link help pages to non-English community centrals at help page namespace (→ Thread:15103)

      Sorry, I don’t know what I want to the language links, but personally it is not troublesome for me to collapse collapsible materials by clicking.

        Loading editor
    • Plover-Y wrote: Thank you for updating the template (^-^)

      As you said, surely the interlanguage links take height so much today (and honestly I don’t like the present situation). But as an editor and non-English user, I don’t want to scroll down dropdown lists and don’t want to scroll down pages to see interlanguage links. I didn’t think dropdown list of languages at community centrals were bad, but Developers wiki has lots of languages to scroll down... (And I think language names list is better than flag navigation)

      Do you feel this modal idea helps? And putting user & content language first in list (as Nanaki and Fng suggested)? I can look into testing these ideas soon.

      In addition, I would like to link help pages to non-English community centrals at help page namespace (→ Thread:15103)

      Help pages can link to non-English CC wikis still - using wikitext like this:

      [[de:w:c:de.community|...]]
      [[es:w:c:comunidad|...]]
      [[fi:w:c:yhteiso|...]]
      [[fr:w:c:communaute|...]]
      [[it:w:c:it.community|...]]
      [[ja:w:c:ja.community|...]]
      [[ko:w:c:ko.community|...]]
      [[nl:w:c:nl.community|...]]
      [[pl:w:c:spolecznosc|...]]
      [[pt:w:c:comunidade|...]]
      [[ru:w:c:ru.community|...]]
      [[vi:w:c:congdong|...]]
      [[zh:w:c:zh.community|...]]
      

      Sorry, I don’t know what I want to the language links, but personally it is not troublesome for me to collapse collapsible materials by clicking.

      By collapsing them, they also become a potential user experience and SEO issue. Editors won't be able to get to them quickly without "jumping content", it won't help the original issues I mentioned (or mobile), and it could confuse search engines.

        Loading editor
    • Speedit wrote: Something like this: Languages_modal.png

      Launched by selecting this: Languages_search.png

      You can see something similar by visiting Wikipedia articles on desktop. They have an interlanguage button that launches a search filter.

      Can this be even legally used site-wide?

        Loading editor
    • I doubt it. I had an alternative idea based on an existing product:

      Languages_table.png

      Pretty easy to generate with JS. I could make it a script that users can install globally and locally. That will allow everyone here to avoid the "Languages" dropdown in general.

      EDIT: The "all" button won't be included - it's for a different use.

        Loading editor
    • And this idea will be located on the same place as the current languages bar?

        Loading editor
    • Yeah. That will give space for the links, but will probably make it personal-only.

        Loading editor
    • design is... too questionable for site-wide use. it is support template, it not supposed to neither take space or draw attention. with such height, the template will push down the content.

        Loading editor
    • It would begin collapsed, and would not be sitewide. Basically a JS Gadget. I agree that it's too conspicuous.. maybe something based on PI/install template style would be better.

        Loading editor
    • So, it will be a separate script for now?

        Loading editor
    • Interwiki menu seems a more suitable place for the language links, though like Nanaki mentions, moving the entry for the user's language to the top would be convenient. Another difference is that it'd be a little harder to create a new language subpage: the Languages template includes a preload edit link for the reader's language if that subpage doesn't exist, and I don't know if that can be done for the interwiki menu.

      A modal seems like many extra clicks, but an in-menu search filter would be neat! (e.g. type 'a' and menu would hide all entries not containing 'a' in name or language code)

        Loading editor
    • I'll try implement an in-menu search filter soon. Prepending a preload edit link if user language doesn't exist is fine.

      Speaking of typing 'a' to search, we will need a database with some kinda romanization (e.g. 'français' vs 'francais')- should be an interesting problem to solve.

        Loading editor
    • Can this action be done using a bot though?

        Loading editor
    • Speedit#23
      we will need a database with some kinda romanization

      seems like we don't: .localeCompare example: 'cs'.localeCompare('Č', 'en')
        Loading editor
    • I'd like to support searching "Nihongo" or "Japanese" for ja etc - Wikipedia does the same. Is there a way to do it without loading a JSON file for these from Dev?

        Loading editor
    • on wikipedia, it is server-side extension: nihongo. u can see how it was done, or just request them (if they don't mind):
      $.getJSON('https://en.wikipedia.org/w/api.php?callback=?', {
          action: 'languagesearch',
          format: 'json',
          formatversion: '2',
          search: 'nihongo'
      });
      
        Loading editor
    • They did it by creating a big bucket in PHP.. which we can't do :/

      I'll upload a much smaller but similar JSON file with all our documentation languages. With 6-hour caching, it should function okay for our needs.

        Loading editor
    • I've chosen to treat the following as missing from LangSelectEdit:

      • interwiki links to the English page
      • user language preload links in interwiki dropdown (see {{I18ndoc}} or this demo)

      These will appear for all users on Dev Wiki, so that it helps translator's ability to create pages. I admit that substituting untranslated pages isn't pleasant, but an I18nEdit update would alleviate that.

      I'll document LanguageSearch soon and publish the gadget.

        Loading editor
    • A number of updates:

      Improvements to editing languages
      LangSelectEdit has had bugs for some time. These have been patched and the script is now ready for migration to the interwiki system.
      Gadgets for better language navigation!
      You can now enable LanguageBox and LanguageSearch in your preferences.
      LanguageBox will kludge the interlanguage links below articles into the old {{Languages}} design. Same position, same styles. Enjoy! :D
      LanguageSearch allows filtering in the page header languages dropdown.

      Soon to come:

      • After the admins talk to staff about ?uselang in our interwiki links (not a standard feature), we'll migrate Module:Languages to the new system.
      • We'll start a thread about Gadgets and what they could be used for.
      • There'll be another discussion about English documentation pages, seeing as LangSelect supports putting the English on the same page now.
        Loading editor
    • languagebox loads data on every page, even if no search was requested. isn't better to load json when it is actually needed only?

        Loading editor
    • I love LanguageBox. I was a bit skeptical of the language change and the reduced functionality it might cause, but with this new stylesheet users will be able to keep the old design if they so desire. Thanks speedo!

        Loading editor
    • Fngplg wrote: languagebox loads data on every page, even if no search was requested. isn't better to load json when it is actually needed only?

      Sure, I'll make it sideload the JSON on hover (like ConsistentNotifications).

        Loading editor
    • Nice work with all this!

      Only odd thing I've notice is that it's not possible to access the English page if your language isn't set to English. For example, see ChatSendButton with German language set: notice the interwiki dropdown still has the label 'English' (I'd expect it to be 'Deutsch'), and there is no 'English' option in dropdown.

      Edit: Also, just noticed that LangSelectEdit changes the talk link from 'Talk:ChatSendButton' to 'Talk:ChatSendButton/de' - I'd have thought it should be the other way around (i.e. change a 'Talk:ChatSendButton/lang' link to 'Talk:ChatSendButton')

        Loading editor
    • Module:Languages now reports the page language selection for ?uselang right.

      For some context, it seems that recent modifications to Languages module haven't taken into account the logical split between subpages and LangSelect pages.

      EDIT: I also will add the data attribute span to the Languages box methods, if we ever vote to revert this thread.

        Loading editor
    • I'm not sure what the issue is, but it looks like Danish and Latin translated docs are causing red links.

        Loading editor
    • The issue is a lack of interlanguage links in these languages. Speedit poked Staff about it again today.

        Loading editor
    • A FANDOM user
        Loading editor
Give Kudos to this message
You've given this message Kudos!
See who gave Kudos to this message