Thanks for your reply! Yes, at the base of it, the site admin will set the default language for the whole site, but there is a need for individual users to choose their own language over that.

I've discovered something interesting that might help solve the language choice persistence problem elegantly. You can set and read cookies using the htaccess: http://www.askapache.com/htaccess/htaccess-fresh.html#Cookie_Manipulation_Tests_mod_rewrite

I could therefore read the language cookie, and set an environment variable which would be picked up by the PHP (much as HTTP_AUTH is handled at the moment). This would remove the need to use a querystring parameter. :)

GetText cannot be used because the template is static and it would break the separation. Translation could be done with a simple search / replace whilst the DOMTemplate is loading the template file. The art is in how we store translation data as to whether this will be bad for future maintenance and development.

“replacing those with placeholders ought to make it more logical as well as more pretty.”

Logical, yes, but we're avoiding logic in the templates :) A template that contains no actual real text is not very pretty, and is not very helpful for somebody trying to read, understand and modify the templates. As NNF has it now is almost perfect since the HTML can be developed independent of the PHP; if at all possible I'd like to keep that attribute.

But it is impossible to avoid repetition like that. Something has to key the English phrases to the foreign ones. In systems like gettext, the English phrase is used as the key so that the template reads more naturally. That is the goal of NNF too, to be readable.

“what if you change the english text later on, even just one character?”

Yeah, that is a problem. When it comes to translation you have to choose a problem to accept and solve the other problems. I’m still debating what problems to solve and what ones to keep.

Given I am developing NNF in English and that any other languages are provided by volunteers only, and that anybody adding their own translation would likely have to know English too (because NNF's code and documentation will remain in English), I theorise that it is best to base translation behaviour around English-by-default, such as in the case of gettext.

Unless there is some kind of identifier mark, then the English text has to be repeated 1. inside each template as filler, and 2. in each translation file as the key to the translated content.

NNF will need an admin option to enable / specify which language translations are available to choose from, including adding their own. The reason for this is that an admin may modify the English heavily (custom skin or what-not) and not be able to update the other languages accordingly and so have to disable them.

Therefore in the instance where a site admin modifies the template English (the default filler), and this breaks translation because the key cannot be found, this won’t be a problem unless those translations are enabled; and the template will fall back to the Admin’s chosen English for those phrases without any code involved. Therefore, there are some benefits to this. That is, it’s nice for NNF to not have to translate English to English, if you get what I mean :)

That's basically the approach I plan to take Akerhielm, the difficult part is choosing what way to do the search / replace it.

Here's a concept that strikes a happy medium:

%
[%IDENTIFIER:The quick brown fox jumps over the lazy dog%]
%

I'd prefer if we didn't have to go back to essentially having template tags, but that may be the only way to do translation without either repeating the English phrases fifty times throughout, or duplicating the whole theme fifty times over.

---

I've decided roughly where to draw the line with translation support:

* Everything intended for the site admin for installing and configuring NNF will be not be translated or support switchable translations (ReadMe, source code, )

* Everything intended for the site users should be translatable

That includes a wide variety of things, some of which are not in the right places in the code atm to support translation so there may be a lot of config file updating to do

* The templates (index / thread / append / delete)
* markup.txt will be moved to an HTML template like above
* Everything currently in 'theme.config.default.php' e.g. the <title> strings

Things I'm not sure about:

* Should the forum's name be translatable?
* The admin's per-forum 'about.html'?
* The Google search URL (should we also allow people to choose other search engines easily? Google is hardcoded atm)
* 'User X added on date Y' & 'This post was deleted by...'; note that these items are inserted permanently into the RSS, so it might not make sense to intermix languages like this if you have multiple users viewing the site in different languages

Kroc added on 26 Jan ’12 · 12:25

Just had an idea about the 'This post was deleted by...' string.
When a post is deleted, the text inserted into the RSS will be the forum's default language. When a user is viewing the forum in a different language, their language will be displayed for this message because NNF knows that the post is deleted (from the `<category>`) and can show the translated text rather than the RSS's content.

The same can't be said of the 'User X added on date Y' string as it's intermixed with the other text. It will just have to be kept in the forum's default language.

Re: forum name translation, good point but I think that for an initial implementation we'll have to leave this out. That's because all the strings that have to be translated are part of the theme and thus very self-contained. The forum

“On the other hand, the about.html of the root forum should be translatable. Because this is a page any language user will visit at some point.”

Very good point, that alone is reason enough; and since all about.htmls are templated by the same line of code, translation support will naturally be site-wide, even if it's not used for every sub-forum.

This does raise a new questions though! How should this actually be handled? I'm guessing that we can have 'about.html' for default and then 'about-de.html' &c. for the translations

Kroc added on 27 Jan ’12 · 08:48

Sorry, I hadn’t noticed your reply David because it had appeared inbetween me writing mine. Yes, that's a more natural way of doing it (as far as HTML is concerned) even if it might be a bit messier.

I don’t think that's workable. NNF is already being used internally within companies and browsers cannot translate such private URLs, either way machine translation isn't good enough.

This feature is more about the site administrator providing the default language and optionally additional translations that fit any custom skin (and therefore text) they’ve made.

I think I’ve found a good, fairly elegant solution to translations that’s much better than even using HTML comments as delimiters; just use XPath!

I noticed that there are a number of HTML attributes that would need to be part of the translation, and that if I used a text database for the translations, it would actually have the ill effect of forcing all themes to adhere to certain element types and attributes. Instead, we can allow the theme-maker to specify however many translation strings they want, to apply to whatever elements/attributes they want, and these decisions not be hard-coded into NNF.

For example; imagine a translation table like this:

% PHP
$LANG = array (

//search box
 '#query@placeholder'		=> 'Google Search…'
,'#go@alt'			=> 'Search'

//header navigation
,'#nnf_add'			=> 'Add Thread'
,'#nnf_rss'			=> 'RSS'
,'//*[@id="index"]/li[1]/a'	=> 'Index'

⋮

);
%

It’s then up to the theme author to define what strings are translatable, not NNF, meaning that different themes can have wildly different text — and be translatable — without consistent text being mandated across the board by NNF (as is with most translation implementations).

I don't want to come across negative, but I do want to clarify where possible to all readers:

“Why not just use `<l10n>The quick brown fox jumps over the lazy dog</l10n>`. I think it looks way nicer that those comments.”

I am not using the comments any more, so thankfully that's no longer an issue. Instead XPath is used to select an element or attribute and then replace the text content. Since we are already selecting elements, there isn't a need to use an `<l10n>` element or otherwise.

“As for storing the selected language, I'd put in into the url”

This just wouldn't work in practice. If I share a link from one language, other users perhaps get a language they don't understand and that isn't helpful. Rather, language is a local, per-user choice and not a public, global choice. Language selection will be persisted using a cookie, and also where possible auto-detected from the browser. Therefore, whatever link they follow, they will see the interface in their chosen language.

I've got basic translation already working with pig-latin, and the chosen implementation is very simple and straight-forward. I still have much to do as there still needs to be a UI for choosing language, and the code to persist selection.

NNF won’t be doing IP look up, so don’t worry :) It will go by your browser language ('intl.accept-languages' in 'about:config'), if not your chosen language in NNF, if not the default language of the forum.