**Warning. This document is a draft**
{{toc numerate=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).
===How it works now: some reminders===
====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., inserts.fr.php 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. wacko.es.php 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.
====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 config.inc.php
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
===Proposed specification===
====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: ((user:WikiAdmin 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
====Proposed rules====
=====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.
* ((user:WikiAdmin 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)
=====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 in|Event| Language to be used after that event and until next event|*
||N|Beginning of a session|The 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|Beginning of a session|The last language chosen by the user||
||Y/N|Closing of the session|N/A||
||N|Log in|The last language chosen by the user||
||Y|Log out|The 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/N|User choose a language|The language chosen by the user||
|#
Notes.
* I suggest that the ~{{PageIndex}} action, if typed with no parameters, do not display "service" pages inserted by the installer (see comment from ((user:DrFreeman 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