[dokuwiki] Re: Multilingual wiki survey...
- From: "Terence J. Grant" <tjgrant@xxxxxxxxxxxx>
- To: dokuwiki@xxxxxxxxxxxxx
- Date: Mon, 12 Jun 2006 16:54:02 -0400
In my notes on the subject, I have the following issues to be
addressed:
- how to switch interface language?
* browser detection is one option (browserlanguagedetection patch)
This is clever...
* an other interesting option would be to choose a language from a
menu/list autobuild through DW, Andreas suggested this could
be done the mediawiki-way using interwiki links
But I think this is a better idea...
http://bugs.splitbrain.org/?do=details&id=834
I put the wrong categories on it though, sorry.
- how to link two pages which are translations of one another?
* simple approach: use dedidated language namespaces (Alexey's
patch and keep the same page names (+ interwiki links)
Right, this is easy to implement without a patch but takes much time
to check for each language. But of course this makes page names
non-obvious for other languages.
* better approach: a plugin which knows that page "gens.txt"
in the <fr> namespace is "people.txt" in <en> namespace, as
pagenames could be translated too (we don't want to force
useheading)
I think this is the closest to what wikipedia(possibly mediawiki as
well) uses-- they simply list all other language versions at the
bottom of the page:
[[ko:ëì]]
[[ja:åé]]
[[vi:Äái tuyát]]
[[zh:åé]]
Though I think this has a problem related to permissions and
associativity. This could easily get out of sync, and you may trust
anyone to translate, but not to modify the original document...
So perhaps something like a "callback tag" to the original document to
identify it as the translation. This way, original documents can
remain read-only and unchanged(if necessary), and the presence of
callback tags could modify metadata on the availability of
translations. What do you think of this idea?
* apache-like approach: hack autoplural to have it expand file
name like apache does (start.txt, start.fr.txt, start.de.txt)
but this could become a nightmare
I had this idea too; but the reason I think we tend to jump to
"alternate namespace, but same names" is that you can easily set
translator permissions per namespace rather than each individual page.
* have only a single page (master source), which contains all
translations (one parsed file, output differs) a la wml:
<fr>texte franÃais</fr><en>english text</en>. Easier to
maintain for authors. Cannot be cached.
I like this idea too. Maybe something like <lang fr> instead. I have a
solution to the cache issue I think-- Give each language its own div,
and only display the one the user wants? Of course then you're sending
n*page_length data for n pages...
* a mixture of dedidated language namespaces + single page
Don't understand this one...
- how to sync translated pages together?
* if a plugin knows which files are associated together (such as
"gens.txt" and people.txt in the above example) it could ease
the update of any page which has a translated sister
* with single page as translations source, that's easy
I think some kind of auto-association scheme would work, perhaps with
the callback tags like I mentioned earlier.
Guy, what do you think of the callback tags idea?
--
--Terence J. Grant(tjgrant@xxxxxxxxxxxx)
‰.Z)"™¨¥Šx%ŠËf¢·¢ú¶m§ÿðŠH¬¦Xn¶¢žŠàÿ¤Šf¢–)à–+-
Other related posts:
