Wedge

We can only use that once we have built the final array, we cannot use it to combine English with other elements during the build process.

For any given arrays, if the same (non indexed) key occurs in both arrays, the left hand array element will be used, as per http://php.net/manual/en/language.operators.array.php so if we load English into $txt, then use += to attempt to overlay another language, it's going to fail.

Also note that there are some instances where strings are actually reused without necessarily being aware of it.I'm thinking instead to attach a script to the post_commit hook of SVN, called on any given commit. If the commit updates anything in /languages/, we have an instant log that something needs to be done. It's all automatable. :D

It's likely to be used if someone posts code. <we:*> on the other hand won't be caught by the replace filter because it'll have been converted to entities and thus the raw form is never exposed to the replacer.Isn't QueryString.php where $scripturl is first defined?

Such as?

It did occur to me, especially as there's a higher percentage of BSD code compared to the rest of Wedge, there's less we've done to it.

$scripturl is the special case, because it's used in a ton of strings as well as throughout the source.

Things like boardurl are rare enough that you can just do a str_replace as needed; no need to wrap it in a special function.

But it doesn't require a page wide regex, just a page wide str_replace as it's constant and source level.Yup. I seem to recall setting up a setlocale call for that purpose, assuming LC_TIME or LC_ALL is still passed. Again this is something I'd like more input because I don't know about other languages and cultures.


Oh, and last I heard, the i18n team is now called Localizers, which isn't really much better, and while I do remember debates about languages, I don't remember much strong debate about how to practically approach these matters, almost as if they were just accepted as faults that weren't going to be fixed. IIRC, the only reason the AM/PM thing happened was because a real[1] team member kicked up a fuss.


Lastly, I wouldn't worry about RTL too much at this time.

1.	The Internationalizers/Localizers have never been considered a real team, even if some tried to treat them as valuable equals. In all honesty I think Akyhne has more power as a consulting dev than he did as Lead Internationalizers.

I know :P From my POV, anything that requires altering a lot of language strings is effectively a language pack candidate.

It would indeed be slower, though I'd suspect it would be much more convenient to use something like <we:script> and replace it in the buffer at the end. It would certainly avoid juggling the variable about so much.

For other stuff like $boardurl, I wouldn't bother, it's just not used enough. But for $scripturl, there is a practical convenience vs performance decision to be made.It's not so much that some people need to translate it, it's more than some languages simply have no concept of am/pm, and use 24 hour systems instead. In fact, I think it is a peculiarity of English the more I read up on it.Hmm, I'm not actually that fussed personally. I'd say that whatever is reliably going to strip it without leaving too much fluff is fine.I want to. I just haven't gotten round to it yet because it's used in a lot of places, just as $txt['in'], $txt['on'] and similar joining clauses are. I'd rather strip them all and use properly constructed phrases, even if it is slower.http://download.simplemachines.org/?smflanguages disagrees with you.

What would really help is if I could talk to people who know more languages; ideally I'd like to speak to people who know Chinese, Russian and Arabic. While I'm aware it's a gross simplification, Japanese, Chinese, Russian and Arabic between them hit up all the key problems in the language files.

Internationalisation is an incredibly complex art, and if I'm honest it's not one I'm that familiar with, but I'd like to think that my gut instinct on the practicalities of it are serving Wedge well.

For example, I'm aware of the whole use of : in strings in the admin panel and other places. My gut instinct tells me that they should be in the language file, not the template, because from my understanding of RTL and the way it's currently handled, you'd risk ending up with <setting> <string>: rather than the more correct <setting> :<string>. But I don't know any RTL languages, my knowledge of French is limited and rusty, my knowledge of other languages even more so (but it's enough to recognise that the constructions used currently do not work consistently outside English)