jbovlaste
jbovlaste copied to clipboard
lojban
Multilingual interface
Vlasisku has all the interface in English. It's completely unacceptable. Vlasisku.ru is running with the same interface although it is to be used by speakers of Russian.
Vlasisku is a separate project, although it is often cited as a model for improvements to jbovlaste. It sounds like its internationalization (or lack thereof) is one aspect not to emulate.
In deed; i18n is something I've always designed for in my jvs2 experiments. I especially think it is a travesty that we don't have our own web services in our own language, Lojban.
One design question here is to what extent the languages should be isolated: when using JVS in Russian, should you only be shown entries in Russian? Personally I think yes, you should only be shown entries in languages matching your preferences (which may be more than one language and come from user preferences or HTTP accept headers) but entries in other languages should still be accessible (like a link "12 entries in other languages" that explicitly shows all entries).
I'd also much prefer something smarter than mere gettext, which is basically the antithesis of Lojban. In my Haskell experiments this has been easy to solve by making all translatable messages data types and translations pure functions:
data Language = English | Lojban | ...
data EntryMsg = EntriesInOtherLanguages Int | ...
instance Message EntryMsg where
msg English (EntriesInOtherLanguages n) = show n ++ " " ++ englishPlural n "entry" ++ " in other languages"
msg Lojban (EntriesInOtherLanguages n) = "li " ++ lojbanIntToPA n ++ ...
Completely imaginary and dumbed down example.
Not very relevant but this is how LMW now works: When you load mw.lojban.org it automatically recognizes the language of your browser (e.g. Japanese) and changes the interface of menus accordingly. Links in the sidebar also start to lead to Japanese versions of pages (i.e. not only names of hyperlinks are localized but urls of them are also localized). Still LMW shows the main page with language flags where you have a second chance to choose your language if LMW determined your language incorrectly. Clearly, all pages in English, Russian etc. still continue to be available for reading if you search for them or open their direct url.
You can also log in, change your language in preferences so that next time you open the website LMW won't guess and load menus and the sidebar in the language you set immediately.
2014-04-05 0:11 GMT+04:00 Dag Odenhall [email protected]:
In deed; i18n is something I've always designed for in my jvs2 experiments. I especially think it is a travesty that we don't have our own web services in our own language, Lojban.
One design question here is to what extent the languages should be isolated: when using JVS in Russian, should you only be shown entries in Russian? Personally I think yes, you should only be shown entries in languages matching your preferences (which may be more than one language and come from user preferences or HTTP accept headers) but entries in other languages should still be accessible (like a link "12 entries in other languages" that explicitly shows all entries).
I'd also much prefer something smarter than mere gettext, which is basically the antithesis of Lojban. In my Haskell experiments this has been easy to solve by making all translatable messages data types and translations pure functions:
data Language = English | Lojban | ...data EntryMsg = EntriesInOtherLanguages Int | ...instance Message EntryMsg where msg English (EntryMsg n) = show n ++ " " ++ englishPlural n "entry" ++ " in other languages" msg Lojban (EntryMsg n) = "li " ++ lojbanIntToPA n ++ ...
Completely imaginary and dumbed down example.
— Reply to this email directly or view it on GitHubhttps://github.com/lojban/jbovlaste/issues/11#issuecomment-39606304 .
Also if one wants to have the whole interface of vlasisku or JVS completely in Lojban then I'm ready. Although, to have a separate localization file with strings to translate would be smarter.