Internationalisation team updates on Universal Language Selector and Project Milkshake

The Internationalisation/Localisation (i18n/l10n) team at the Wikimedia Foundation works on a set of tasks every two weeks. The following describes the work we’ve done over the past month.

We’ve worked on making the Universal Language Selector (ULS) functional according to the design prototypes, and it is now available for alpha testing on http://translatewiki.net. Please help us test it in your language. The features listed below are the highlights from the development work done on the ULS:

  • Supporting approximate search, which will give results even with typos in it.
  • Ability to do language search using any language: Search using the translation of language names in other language names.
  • Auto-complete for search across languages.
  • Writing systems that belong to the same family are visually grouped together.

Languages are grouped by writing system.

Fuzzy search: Searching 'tail' returns 'Thai' and 'Tamil'.

Another focus of our work has been Project Milkshake, an effort to release our existing internationalisation-related JavaScript components as standard jQuery libraries. These libraries —dually licensed under GPL and MIT license— will not only help us in integrating our tools better with the Universal Language Selector, but will also let other people reuse them widely in other web projects, and get the benefits of internationalisation components just by using these libraries:

  • jquery.i18n — A library to provide full i18n framework that supports parameter replacements and grammar-, plural-, and gender-dependent translations;
  • jquery.webfonts — A library to provide webfonts support, developed from WebFonts extension;
  • jquery.ime —A library to provide input methods in the browser, developed from Narayam extension;
  • jquery.uls will also be available soon as we make more progress on ULS.

We continued to improve translation user experience by making the screens more user-friendly and making the process more efficient for translators. We are currently working on the prototypes. This aims to increase the number of translators, as well as provide an interface that helps them spend their time as efficiently as possible. In the coming weeks, we will perform in-depth usability tests with several members of the community. You can learn more about them at the Translation UX page and, if you are interested, consider volunteering to participate in the usability tests.

As usual, apart from these, we continued fixing issues that were reported in Bugzilla, as well as translation-related issues in translatewiki.net. Narayam, the input tool, was deployed in Bengali Wikisource. If you need Narayam / WebFonts enabled on your wiki, please open a bug in bugzilla.

In the coming weeks, we will be working on integrating Narayam and WebFonts as part of language tools in Universal Language Selector, completing the translation UX improvements.

We will also be having our monthly online office hours on August 15 16:30 UTC (8:30 PDT). This is an opportunity to ask the development team questions about current and upcoming i18n features. The team will also share updates on exciting work happening on the ULS, translation workflow enhancements and additional language support on Narayam and Webfonts.

Please feel free to contact us through the mediawiki-i18n mailing list.

Srikanth Lakshmanan, Internationalisation/Localisation Outreach / QA Engineer

5 Show

5 Comments on Internationalisation team updates on Universal Language Selector and Project Milkshake

Srikanth Lakshmanan 2 years

Thanks everyone for your comments.

@Kenneth The idea of grouping languages into regions is that people will be able to identify them easily as speakers will anyway know the geographical origin of the language.

As for the two letter codes, We shall have it display complete region name once it is ready for internationalization.

@Kenneth, @Neilk,
We don’t have prioritized search ranking now and at some point are thinking of GeoIP based suggestions on ULS which might satisfy large number of users to change language without searching.

NeilK 2 years

Does language popularity matter at all in the search ranking? I understand the desire to be egalitarian, but I think this might be affecting usability too much. I feel there ought to be quicker ways to find English, German, Chinese, etc… I assume you are going to test those?

Stultus 2 years

@Kenneth Languages are grouped by writing system.not by geography.

bawolff 2 years

“The two-letter codes which appear at the top of the language region groupings would be better spelled out (in the same language as the map labels), as they are in some cases quite cryptic right now (eg, “AF” for Africa).”

+1 I spend a good minute figuring out NA stood for north america instead of not applicable.

Kenneth 2 years

Grouping languages by geography to me just seems fundamentally wrong. Many people today live in territories where they speak a language other than the officially recognized languages for those territories. It also results in a lot of duplication – eg, English practically everywhere.

If you are going to go with this approach though:
– Would it make sense to show languages within a region grouped first by popularity (measured by whatever metric you like)? If I click Europe, I expect to see English, French, German, Italian, Russian, Spanish and Polish first, not a bunch of relatively small languages, all of which use the Cyrillic alphabet.
– The two-letter codes which appear at the top of the language region groupings would be better spelled out (in the same language as the map labels), as they are in some cases quite cryptic right now (eg, “AF” for Africa).

Leave a Reply

Your email address will not be published. Required fields are marked *