An overview of multilingual support in Crabgrass:
- detection of desired language:
- use the language specified in the url.
- if a session is active, use that setting.
- if the browser has a preference, use that setting.
- try to guess from the user’s ip address.
- user interface elements will be translated using globalize. users will be able to add new translations within the application.
- translation of user profile information: every value in a user’s profile, such as their hobbies or whatever, will have a language tag associated with it.
- translation of wiki pages: every wiki has a revision history of all its changes. in the future, each wiki will also have different language editions.
stuff not translated¶
The current plan is to not allow translation of comments, poll/ballot choices, or tags.
Also, there is no plan to translate the url of a page. For example, this page has the name ‘multilingual-content’ that shows up in the url. The user would not be able to specify a different name for the url for each translated edition.
page summaries should be translated, but I am not yet sure how to do this. page summaries are not used yet anyway.
how wiki translation would work¶
Every wiki will have multiple editions, one for each language. Each language edition, in turn, has multiple versions, one for each time there is a change to the text (multiple edits within 1/2 hour from the same person don’t create multiple versions).
If you visit a page there will be a link to allow you to translate the page. This will open a special editor, where you see the source text in the top half of the window and the edit box in the bottom half (or maybe side to side?).
Version numbers are kept separate for the source language edition and all the translations. If the source language edition is edited, then all the other editions are marked as needing translation. If you edit a edition that needs to have its translation updated, the top half of the window will show what changes were made to the source language edition since the edition you are changing was last edited.
I guess there should also be a button that says ‘this translation is now up to date’, instead of just assuming that the person was able to translate the whole thing.
It would also be cool if you could click a button and have it generate a text file with all the editions concatenated together, for sending in an email.
It would also be cool if you could get a report of all the pages in your groups that need translation.
language code in the url¶
Should the language code be in the URL? For example es.riseup.net/mygroup or pt.riseup.net/mygroup or riseup.net/es/mygroup.
advantages:
- you can copy and paste the url, and people will see what you see.
- in order for proxy-caching to work, you must not provide different content for the same url. in the case of riseup.net, we are not going to benefit from proxy-caching anyway, because everything is over ssl. but for non-ssl sites, proxy-caching could be a big benefit.
problems:
- if you copy and paste the url, other people will see what you see instead of seeing the language as set by their browser.
- if we do domain name encoding of the language (ie en.riseup.net) on an ssl site, then we need to create new certificates for each possible language.
- if we do path encoding of the language (ie riseup.net/en) then this make all the routes more complicated and less concise.
- what do we do about country code? pt_br.riseup.net is not very pretty, but it should maybe be different from pt_pt.riseup.net.
proposed answers:
- For non-ssl connections, use URLs that encode the language in the domain.
- For ssl connection, do not encode the language in the URL.
