Rethinking about the multilingual content support... the original suggestion (default file.txt and associated/translated file.txt.lang) is maybe not well suited for translators' work. Usually a translator expects to edit a content and change strings in situ to his/her native language then saves his/her work. This work is made easier if the translator sees both the original strings (for ex. in english) and his translated strings (for ex. in german). Website META Language (wml) has adopted a nice approach for localisation of docs: <lang> tags are supported by the parser. This is better than having one default wiki file (file.txt) plus one file for each translated language (file.txt.de, file.txt.es, etc.) as when a change is done in the default file translated files are no longer in sync.
So I'd rather imagine having support for <lang></lang> tags inside dokuwiki and handle several languages directly from the single file.txt. The language should be selected according to the browser language preference (see in
http://wiki.splitbrain.org/wiki:tipsandtricks:browserlanguagedetection), the UI adjusted accordingly and the appropriate <lang></lang> tags parsed. For ex. if the browser tells "Accept-Language: de" and if file.txt contains something like:
<en>Hello !</en><de>Gutten Morgen</de><fr>Bonjour</fr>
dokuwiki would adjust the UI language to german (if available) and would parse the file.txt (and any other file) giving a preference to <de></de> tags it would find and ignoring other language tags (except if <de> tags could not be found). To write a document (before or without translation) one would just write it without any <lang> tag.
Thus we would need browser language prefs detection (already available) and <lang> tags defined in the parser. Do we even need a conf parameter to enable/disable this multilingual support?