I’ve heard word from an NNF contributor deploying NNF internally at his company that he has a requirement for translation support.
Now, supporting translation is a *lot* harder than it seems when you give the implementation some thought, and I’m interested in people's input given the following consideration:
* There is no session (and can't be). How do we both provide the choice of language to the user [UI], and how do we persist this choice? Off the top of my head, I would consider passing a query string around to set the language, but this might get lost with POSTs and redirects. The language choice could be part of the URL scheme and parsed out by the .htaccess (possibly even setting an environment variable); but there may be another way of doing it
* Because NNF does not store any data on users except their password, there isn't any currently existing way to persist a per-user choice of language — they would have to choose it each time they visited the site. Cookies seem like the only answer to this at this time. It’s not really okay to require a user to sign-in to get their desired language because they may not be able to read the link to sign in
* Providing language translations bundled with NNF could restrict my ability to develop the product further due to reliance on contacting X-number of volunteers to translation new strings whenever I prepare a change. I like the speed at which I can push out new versions, and I wouldn't want to go down a route that leaves my hands tied especially when I am neither being paid for any of this, and can’t pay anybody either. For that reason it’s unlikely NNF will contain many translations out-of-the-box, but it is vital that the implementation allows people to provide their own languages *without modifying the original source files* (i.e. via config.php / theme.config.php and additional external files not tracked in the GIT repositry)
* What is the right way to translate within NNF? Search and replace? By doing that, you have to duplicate the template's text somewhere else, many times over (for each translation to find the original English text), meaning that to change the English creates a search/replace nightmare. What about duplicating the template files for each language? — everything needed is certainly contained within in clear context (easy to do the translation), but it’s a very large amount of duplicate data and too much of a pain if you want to make HTML changes. Choosing the right data-format and method of text substitution is actually very hard to do elegantly and without creating a burden of maintenance and complexity on anybody who doesn’t want or need the translation capability (the single reason thus far for me not implementing it)
All in all, this is a very difficult feature to implement elegantly and cleanly. I would prefer to really fret the details with this and be able to implement something that is above and beyond what any other software project is doing because that's what NNF does—questions what everybody else is doing and rejects it for its sloppiness and complexity. NNF would not be "NoNonsense" if it used something like GetText :P
Your consideration is desired and appreciated.
Kroc added on
Just realised a few more things:
* Markup.txt would need to be moved to a templated page and translated, that's quite a lot of text!
* If NNF bundled additional translations, would that mean that the ReadMe would have to be translated? That's way beyond what to expect volunteers to translate and impossible to maintain if the ReadMe is changing every couple of releases
* What about 'about.html'? Would the site admin have to provide multiple versions if they supported multiple translations?
This is a lot of difficult stuff.
I think the first step is clearly defining where the actual translation support boundaries lie -- what is included, what is not. What is provided by NNF, and what is provided by the site admin.