Proposed Specifications For Languages Holding

Warning. This document is a draft

1. Purpose of this document

This document is intended as a proposal to clarify in which language the texts included in WackoWiki's user interface (abbreviated as UI in this document) should be displayed.

Of course we are speaking about the texts displayed by the application (WackoWiki) itself, not about the content of the pages as edited by the end users (abbreviated as EU in this document).

2. How it works now: some reminders

2.1. Files containing the translated texts for each language

In order for WackoWiki to be multilingual at the UI level, it has to have a specific version of (every, if possible) text to display for each available language.

Implementation in WackoWiki:

  • The setup/lang directory of the source archive include one file for each language, containing the localized version of all texts to be displayed during installation, e.g., for French.
  • The lang directory of the source archive include one file for each language, containing the localized version of all texts to be displayed during WackoWiki's usage, e.g. for Spanish.
  • During installation some pages are inserted in order to facilitate access to some basic functions or actions, in all languages available if "mutilingual" is chosen, in the language chosen if it is not.

Please note that in languages files some texts can stay untranslated; in that case the English text will probably be used, as generally the translator uses the English file as a template.

2.2. What is at present considered to determine the language to be used to display texts

To determine in which language it should display each text, WackoWiki takes into account several factors:

  1. the "multilanguage" setting in wakka.config.php (the configuration file of WackoWiki)
  2. the default "language" setting in
  3. the available language files in the lang directory
  4. the fact that the user be anonymous or logged in
  5. if the user is logged in, his/her preferred language, as set-up through the UserSettings function
  6. if present, the first two characters of the HTTP accept_language header (c.f. RFC 2616 § 14.4 Accept-Language) supplied by the client. In our case, the client is the browser used by the EU. Note that in some browsers -- e.g. Firefox or Opera -- the EU can set up a parameter according to which the header is built, in others -- e.g. Konqueror -- he/she can't

3. Proposed specification

3.1. Rationale

Let's bear in mind that:

  • To access a website the EU can use his/her own computer, at home or at work, or any other one, for instance in an Internet Café or hotel while traveling abroad. In many cases he/she won't be able to set up or change the accept-language header sent by the user agent he/she uses.
  • Whenever possible, the language preferred by the EU should be used, be he/she connected or not. Here "possible" imply that following conditions be met:
    • the EU can indicate his preferred language through the UI
    • this language is available on the wiki to which he/she wants to access; the conditions for availability being the presence of the language file in the lang directory and (the language chosen is the one set-up in the configuration file or the wiki is set up as multilingual).
  • WackoWiki can be multilingual or not, at the administrator's choice. This choice being proposed, it should be respected -- though I do not see what could be the inconvenience of having a multilingual wiki from the administrator's stand point: the fact that the UI be multilingual do not prevent all discussions to occur in only one language, if this is the rule in the organization running the wiki.
    • nb: WikiAdmin - not cluttering the index with countless pages? guess there should be an option to install them only a subset of the available languages [base pages] - and here I discovered an additional aspect with links to pages provided within the language file -> then it can happen the user got an empty link (additional each page has its own language settings -> lantin1 vs ...)

Note. For now the UI can be monolingual or multilingual but as stated above my recommendation is that in a _not_so_distant_future_ the UI be multilingual, period. For that reason:

  1. among the following proposed rules, those which apply to "not multilingual" wikis will be obsoleted if/wen all wiki will be multilingual
  2. this apply as well to the proposed implementation
  3. one of the intents of that proposed implementation is to ease the transition

3.2. Proposed rules

3.2.1. Overview

  • As long as the administrator is given the choice between a mono or multilingual UI at time of install he/she should be allowed to change this choice later.
  • If the wiki is not set up as multilingual, the language used will always be the one set up in the configuration file, disregarding any other consideration.
    • WikiAdmin - atm this is implemented inconsistently for GUEST, User, Registration and autodetection (e.g. as user I can switch the language although multilanguage is off)
  • If the wiki is set up as multilingual, the following rules apply.
  • The EU should be given the choice of any of the languages available for this wiki :
    • If the EU is logged in his/her choice will last until he/she explicitly changes it, or he/she logs out.
    • If the EU is not logged in his/her choice will last until he/she or someone else changes the language setting.
  • If the EU hasn't expressed his/her preferred language and the HTTP accept-language value includes an available language with q=1, use it; else use the language set up by the wiki's administrator (in the configuration file)

3.2.2. Proposed implementation

Warning. In some case this proposal is consistent with the way things work in 4.3RC1, in others it is not. I didn't check that for now; a fortiori the amount of work necessary to implement it is unknown at this stage.

  • During installation, insert pages to allow basic functions' usage in all available language in all cases, i.e. the wiki being set up as multilingual or not.
  • In all cases -- i.e., the wiki being multilingual or not -- the "language" parameter in the configuration file should contain one and only one value, matching an available language. This should be checked in case of language change after installation.
  • If the wiki is multilingual, allow users to choose among available languages only.
  • If the wiki is monolingual -- i.e. the "multilingual" parameter in the configuration file takes the value "0" --, no language choice is given to the EU. In that case display all texts in the UI according to the value of the "language" parameter in the same file.
  • If the wiki is multilingual, give the user the possibility of choosing the language of the UI only through a drop-down list on the home page.
  • If the wiki is multilingual and the user is logged in, record permanently his/her last language choice.
  • In case of a multilingual wiki, the language used at any point of time is indicated in following decision table:

User initially logged inEvent Language to be used after that event and until next event
NBeginning of a sessionThe first language with q=1 indicated in the HTTP accept-language value if available, else the language corresponding to the value of the "language" parameter in the configuration file
YBeginning of a sessionThe last language chosen by the user
Y/NClosing of the sessionN/A
NLog inThe last language chosen by the user
YLog outThe first language with q=1 indicated in the HTTP accept-language value if available, else the language corresponding to the value of the "language" parameter in the configuration file
Y/NUser choose a languageThe language chosen by the user


  • I suggest that the {{PageIndex}} action, if typed with no parameters, do not display "service" pages inserted by the installer (see comment from DrFreeman on that topic).
  • Typical beginning of a session occur when requesting a wiki page for the first time after the browser have been closed
  • Typical closing of a session occur when closing the browser or as a consequence of a time-out


  1. Comment 124

    There are two unneccessary states:
    • Language chosen by user = N applies only to unregistered users. When user become registered, he can set the language, and WackoWiki provides default value -- the same which chosen (automatically or not) for the registration UI.
    • Language indicated in the configuration file applies only to monolingual WackoWiki instances and means that the administrator already choose the language for users. Null value indicates multilingual UI, separate configuration parameter for multilingual state is not needed.
  2. Comment 125

    The second question is about the multilingual service pages. It's semantically incorrect to insert pages in different languages in the one wiki, but even without the support of UTF-8. For example, installing WackoWiki on my site, I do not expect the users from Greece and did not want to see the Greek names in the page list of root cluster. If there will be Greek in future, I should be able to add support for Greek language through simply copying of the necessary language files into the WackoWiki directory.

    Since service pages are always rendering by the actions, there are not need to store all of them as separate instances, just one is enough. Thus the service pages will always have single (canonical) name, based on the default language of this wiki instance. I think that it will be English even if the main audience of the site will be other.
  3. Comment 126

    DrFreeman, thank you for your remarks.
    First question:
    • I agree with your statement that Language chosen by user = N applies only to unregistered user, provided that you replace unregistered by not connected.
    • but then if language indicated in the configuration file applies only to monolingual Wacko Wiki instance, how do we define the default language at registration time ?

    Second question:
    • Anyhow, we should insure that if/when a language is made available, all service pages are inserted. It seems me simpler to insert all service pages in all available languages at time of install, but this only my opinion.
    • If the wiki is to be truly multilingual, IMO service pages names should be multilingual too.
    • I agree that it's not nice to see all services pages in the page list of the root cluster. But there could be a mechanism not to display it, may be based of the value of the user field in the pages table (do not display if it is WackoInstaller), or --probably safer -- if the tag or supertag field matches a record in a list of service pages.
  4. Comment 127

    First question:
    • OK, but not logged in :-)
    • The default language at the registration time should be provided from the user's browser. When not, I agree that the default language is needed. But only for that kind of users that not yet logged in.

    Second question:
    • If the wiki is truly multilingual, it should provide a mechanism to handle language versions of the pages, which not yet implemented for WackoWiki. I know only one truly multilingual site powered by WackoWiki -- this site. It provides "cluster per language" ideology. Let's think that page names are identifiers, "canonical" names, that's right.
    • I've opposed earlier against of use of identifiers in the human-readable text, also known as wiki links and tiki-wiki links. Identifiers are identifiers, it's computer language, not human one. Page names are identifiers, like file names. They are similar to human words, but have own syntax and semantics. System files always have the same name in all localizations. Service pages might too.
  5. Comment 128

    Heh, I'm not lonesome:
    В частности, от поддержки ВикиИмен оказалось больше вреда, чем блага, поскольку большинство страниц раскиданы по кластерам, а не размещены в корне сайта, и экранировать все встречающиеся слова со смешанным регистром не слишком удобно.

    Translation by Google&me:
    In particular, the support of wiki names proved out more harm than good, because most of the pages are scattered to clusters, rather than placed in the root site, and escape all mixed-case words is not very convenient.

    Thanks Martin for link.
  6. Comment 129

    First question.
    • Granted. I still have to learn English :-(
    • There are cases where HTTP Accept Language header sent by the browser do not match user's mother tongue. This can be considered a minor issue though for logged in users, as they are allowed to choose their language during registration. But I'd prefer the administrator be able to set up a default language for not logged in users.

    Second question:
    • By truly multilingual, I mean at the UI level, I am not speaking about content produced by users.
    • If the administrators of the wiki prefer all page names be in only one language, for now AFAIK the best they can do is inform their user. As for service pages names, at least for my own wiki I prefer it be localized -- but do not appear in the standard index, as stated earlier.