Newly introduced Mobile LJ scheme isn't as efficient as it could be.
Short, concise description of the idea
To allow wider support of LJ access from mobile devices, newly introduced Mobile scheme should be made non-Unicode.
Full description of the idea
In the last feature announce LJ team presented Mobile LJ scheme: http://www.livejournal.com/mobile/
It's supposed to be optimized for using on mobile devices, with almost no graphics, lightweight pages etc. There are two login modes - via SSL and via plain-text login - to allow access from any device.
The only problem with the scheme is that it is Unicode - as Livejournal itself. But some mobile devices (as all PalmOS-based devices and some mobile phones) don't support Unicode. It prevents LJ from being accessed via that devices. If it'd be possible to translate page encoding of Mobile LJ scheme to non-Unicode, this scheme would be much more usable for mobile devices owners.
I'm not sure, how this should work. Probably, there should be several encoding translation tables and the one for each user can be selected either on login from the /mobile/ page or from the Site Settings (http://www.livejournal.com/manage/siteopts.bml) page.
- LJ will be accessible from not Unicode-aware browsers/systems/devices.
- LJ Mobile scheme will be even more 'lightweight' in terms of network traffic. That term is especially important for access from mobile devices.
An ordered list of problems/issues involved
- Neccessity to provide a set of encoding translation tables which would cover as wide range of languages as possible.
An organized list, or a few short paragraphs detailing suggestions for implementation
- Things look rather simple. Forst of all, appropriate set of translation tables should be implemented.
- Then each user of Mobile scheme should be able to choose one he prefer (I suppose Unicode encoding should be left as default 'no translation' table).
- After that, all pages accessed by the user after login via the Mobile scheme should be translated on-the-fly by means of the choosen translation table before writing to HTTP response.