Martin Atkins (mart) wrote in lj_dev,
Martin Atkins

Translating the Client Protocol

Right now the server sends some stuff to clients on login which they are expected to just display. Now that there are non-English clients (such as the Russian version of Sema's client), I think it's about time the protocol learnt to deal with other languages too. To this end, I propose the following very simple solution.

Firstly, add a new hook into the translation system for the protocol messages. This includes the Web menu, and possibly other things I'm not thinking of. Since the Web menu is heirarchical, it seems logical to call the translation key things something like webmenu.recententries and webmenu.settings.personalinfo. This would be separate to the normal BML part, just like FAQs are, perhaps called something like 'clients' or somesuch. Alternatively, it could just use the same part BML does, if that's easier. It doesn't really matter incredibly if they're in a separate "namespace".

Now, I sat and pondered how clients should communicate their language with the server. One option was to use the Accept-Language HTTP header, which has the advantage of being standard and able to specify language preferences, but at the same time is probably overkill for what LJ needs. Instead, I think adding a protocol parameter clientlanguage would be a better idea, which takes only one standard ISO language code communicating what language the client's interface is in. This information does not infer anything else beyond that, and the server will only use it for selecting text which is intended to appear in the interface. For now, this can just be sent on login. If other protocol modes start to send languagish stuff in the future, the parameter can be added to those as well. I don't consider it harmful to add it later because old clients won't be aware of the new natural language data anyway, so they'll just ignore it rather than displaying it in the wrong language.

The server will look at this language code and use it to choose a language, and if that language is available the Web menu will be returned in that language and the client will display it as normal. I don't think it's really important to tell the client what language the Web menu is in, since the only acceptable course of action if the language doesn't match would be to display it in English anyway, and any untranslated strings will be returned in English even if the selected language exists.

One distinction I do think is worth making is between the different language settings that might be around in the future. This only deals with client interface language; that is, the language which the client's interface appears in to the user. Another kind of language setting which will become important soon is journal language, which is the primary language a user writes their journal in (with, of course, overrides for specific entries possible). These two don't necessarily need to match. The reason I brought up journal language is because I think the moodlist should be returned in the journal language rather than the client interface language, since users are more likely to write the mood in the language they wrote their entry in anyway.

So, this change is simple enough. Clients which don't send language will just get US English as they did before. Sema's Russian version will be able to get a web menu translated into Russian, and in the future other non-English versions of clients will be able to get menus which go with their interface too. If anyone sees any issue with this setup, please let me know.

Update: I forgot about the all-important error messages. These already have ID numbers associated with them so abstracting them out into the translation interface should be pretty easy, but of course this means that clientlanguage would need to be sent with every request.


  • Post a new comment


    Anonymous comments are disabled in this journal

    default userpic

    Your reply will be screened

    Your IP address will be recorded