Mobile i18n

The ability to read and write Wikimedia content is a first premise, critical for those languages using scripts with poor or no commercial support. Installing fonts and language packs can be trickier or even impossible in certain mobile platforms or in certain devices distributed by certain operators. As a rule of thumb, cheaper devices have a more restricted expandability - and many times are those cheap devices the ones most commonly used by the speakers of those unsupported languages...

Mobile i18n Group: Mobile Start: 2012-01-01 End: 2012-03-01 Team members: Brion, Yuvi, Santhosh Lead: Brion

Language support includes many areas and actually some of the most demanding for a device vendor (e.g. all pre-installed apps localized in language XX) are not critical for Wikimedia projects. What really matters for us is:

• Fonts supported in browser.
  • Use of existing fonts is generally automatic. Yay!
• Possibility to install additional fonts.
  • Extend WebFonts to the mobile interface. Needs some UI work for selection, otherwise ought to be easy.
• Text input supported.
  • Getting JS transliterating IMEs working on the mobile web should cover most cases.
• Possibility to install additional virtual keyboards.
  • On Android we can make a native virtual keyboard that provides our transliterations for all languages. This would work with our apps etc. Probably a good investment, but could be lowered in priority since others can theoretically do this.
• Text prediction supported.
• Possibility to install additional predicted languages.
• Dictionaries supported.
• Possibility to install additional dictionaries.
  • outside our scope for now

Unicode support

When a platform supports Unicode, we can send web fonts to a device and make texts readable. What we need to do is test the extend keyboards on plarforms react like keyboards on computers. When they do, the Narayam extension may allow for entering texts on a device.

The advantage of providing web fonts is that it obviates the need for people to install fonts. This will substantially increase our reach as most people do not want/dare to do things like installing fonts

When a platform does not support Unicode, we can not directly be read. When people can use Opera Mini, they can use this to get text rendered as graphics. This technology is also used by websites as the BBC. When we are to support this, we need to be able to recognise the device as one such. It may be that we want to provide graphics in a size optimised for a screen.

• Probably not practical, and would have issues with input support?

IMEs on Mobile

iOS

Current Situation

iOS in general has better language support than Android - including built in IMEs. However, additional IMEs can not be installed - you are stuck with whatever Apple gives you. There exist a lot of apps that provide functionality equivalent to an IME. You type your characters in, and then copy paste it to wherever you want. This is highly cubersome and requires a lot of task switching - but is the only method available on non-jail broken phones. And many of these apps for many languages are not free.

Picked Solution

Develop an App that lets people pick an IME, type in it, and copy paste to wherever (sortof done [1])

Android

Current Situation

The biggest issue for language support in Android is rendering support rather than IMEs. Android 2.x usually has very bad Indic rendering support, and Can Not Be Fixed(TM). 4.0 had intermittent support inside webkit, and 4.1 bought full rendering support (though bugs still persist).

Custom IMEs can be installed by the user - this is as simple as downloading an 'app' from the Play store. IMEs for a lot of languages already exist, but the quality is usually not upto the default keyboard standards. Some are paid apps too - and switching languages is a pain.

Solution

Fork the default Google Android IME, add support for a lot more languages to it (with rules from jQuery.IME). This can be shipped as an app for people to use, and then we could also 'lobby' google to include this in the default builds

1. Get LatinIME (android default keyboard) to build properly ( Done Github. Uses 4.1 keyboard, rather than 4.2, due to compilation issues with the latter)
2. Write a small tool to convert the jQuery.IME JS keymappings to a format easily understood by Java
3. Port jQuery.IME's text transformation engine to Java
4. Find a way to port the jQuery.IME tests to Java
5. Figure out which Key Mappings to actually port (only phonetic and transliteration based ones - we are not doing custom layouts)
6. Test, test, test!

What we are not doing

1. We aren't handling fonts. Rendering is broken, not fonts - and can not be fixed on our end