Some ideas for making the Wiki multilingual:
Give translations the same pagename with a language prefix. For instance, the Spanish translation of /PackageManagement/Yum/Priorities could be stored as /es/PackageManagement/Yum/Priorities
Maybe the page names could be translated too. For instance, the Spanish translation of /PackageManagament/Yum/Priorities could be stored as /AdministraciónDePaquetes/Yum/Priorities. Own names, like Yum, Priorities, Protectbase, etc, remain the same. See what moinmoin recommend us on HelpOnLanguages.
I don't think that is a good idea, at this moment. First of all, it breaks our redirection plugin (that handles non-existing translation pages) if links are present, but the actual pages aren't. Second, with the same page names we could (in the future) run a script that automatically shows the staleness of translations. Once we have more translations, I think this becomes necessary. Volunteers come and go, and it would be useful to get a quick overview of the state of a Wiki translation. A potential workaround is to get proper support for referencing to original pages (like described below). -- DanielDeKok
Could our redirection plugin be modified to work over a dictionary page ? It could parse a dictionary page and build urls as many languages as we have. For example, if a AdministraciónDePaquetes/Yum/Priorities Spanish translation page doesn't exist, we could parse all dictionary pages (see what are defined in wikiconfig.py) to find its English equivalent and show it. In this example it would match at SpanishDict page where there is a line like the following:
PackageManagement:: AdministraciónDePaquetesA search must be done for each level in the url. Because Yum and Priorities are own names no match is found on dictionary pages, so they are used as they are. This way, non-english users could see breadcrumbs in its mother tongue. And we'll have a place to administer/discuss translation names efficiently, don't you think ?
Use relative links to pages, rather than absolute links or free links. For instance, to link to the "Bar" subpage, you could use the following link: [:/bar:Foobar].
- Move the English pages to a /en/ prefix.
- Only allow translations of English pages in other language "subspaces" (to help the editing team to determine how up to date translations are).
- Can we allow people to first create their "other language page" if they're also working on an english version which might come in a bit later?
Sounds good to me. Maybe someone can write up some code to make a per page-status? Something like this looks nice (but with page names in the first column, and versions of translations in the other columns). But maybe this is to fancy.
- What about adding something along the lines of:
## OriginalPage /PackageManagement/Rpm ## OriginalPageRevision 2Which would allow for future analysis of "staleness" of pages, etc.
- Add a tag to identify on what original English version a translation was based.
- Can we use google translate to offer pages in languages which have no translation ?
- I just ran this page through translate.google.com and would say: No. Even this page - not having any technical content whatsoever - sounds funny, but is rather useless when automatically translated to german. Running the Repositories/ page through that gives me a result which I wouldn't be able to work with.
- What should be done with untranslated pages -- link to the English page?
It would be nice to provide the English version automatically (with a nice message that the native version does not exist). show.py is a simple sample (plugin) implementation of this idea.