Wedge

Pretty sure there's no way to deal with that.
Only 'fix' would be for Transifex to allow authors to determine that ALL strings should be translatable, unless they're matched by a regexp of our choice, for instance in our case, '\$txt\[[^]]+]'... And even then, it won't allow translators to add or remove elements of an array.

As such, I'm afraid Transifex isn't the right place to translate Wedge. Wedge is too smart for it...

[Commit revision b0e0c47]
Author: Nao
Date: Tue, 03 Jun 2014 19:24:15 +0200
Stats: 1 file changed; +6 (insertions), -5 (deletions)

• Wess didn't allow @if tests to evaluate lone variables as boolean if they were set to an empty string (e.g. $window_bg = '', @if $window_bg background: $window_bg @endif didn't work), while 'false' and '0' values worked fine. I like single-byte fixes. (Class-CSS.php)
• Still in Wess, non-math() functions were only allowed to use unit-less parameters, e.g. with $var = 6px, math($var / 3) was allowed, but round(math($var / 3)) wouldn't work because it was parsed to round(2px). It should now properly return '2px'. (Class-CSS.php)

---

[Commit revision 05e76c9]
Author: Nao
Date: Tue, 03 Jun 2014 23:50:25 +0200
Stats: 1 file changed; +4 (insertions), -3 (deletions)

• Also applied previous emptiness fix to @elseif commands. (Class-CSS.php)
• Empty @elseif commands were internally seen as empty strings and explicitly seen as 'true', when I should have set them to 'true' directly, and ensured that an empty string is a no-go. This is more logical. (Class-CSS.php)
• Wess will now automatically dismiss properties with empty contents. For instance, "background: $bg" no longer needs to be enclosed in an "@if $bg" test to ensure skinners can disable the background. Please note that @if $bg would still be necessary in situations where the property uses the variable but adds something else to it, for instance "background: $bg, $bg2" or something like that. (Class-CSS.php)
• I've updated my CSS files to reflect this change, but they're not ready for commit right now, so it'll have to wait more.

---

[Commit revision 030011b]
Author: Nao
Date: Wed, 04 Jun 2014 00:03:52 +0200
Stats: 1 file changed; +1 (insertion), -1 (deletion)

• Wrong language string. (ModerationCenter.template.php)

---

[Commit revision 06daf04]
Author: Nao
Date: Wed, 04 Jun 2014 00:05:10 +0200
Stats: 1 file changed; +1 (insertion), -1 (deletion)

• Wow, a CSS typo! Woot! (mana.css)

---

[Commit revision 50a3205]
Author: Nao
Date: Wed, 04 Jun 2014 00:50:59 +0200
Stats: 1 file changed; +1 (insertion), -0 (deletion)

• Moved topic notifications weren't outputting the proper URL in e-mails. (notifiers/Move.php)

Should be 100% fixed now, tested locally and fixed it (a last-minute change, as often with me... Please forbid me from doing last-minute changes in the future just for the sake of commititng cooler-looking code......)

PS: please refrain from marking a topic as fixed if it isn't 100% done, it could get confusing ;)

Don't waste your time on htaccess files...
The simple fact that it shows wwwRedirect in the URL means that there's a problem with the loadConstants function, in QueryString.php...

Interestingly, I fixed a bug precisely in that area earlier today (I only just committed it though), but it's not directly related to your problem. I found the bug when I tried to access my test forum from my girlfriend's laptop ('Penny Dreadful' was getting dreadfully boring), and it gave me strange graphics and broken links with... wwwRedirect in them.

I'm assuming that the bug is due to the fact that Wedge is built upon the fact that the board URL doesn't have a www in it, but adds a few lines of code to automatically change links to the subdomain-less version if you use www. However, I never tested the other way around....

I'll look into it tomorrow, it's bed time for me.

[Commit revision a05be18]
Author: Nao
Date: Mon, 02 Jun 2014 19:45:10 +0200
Stats: 1 file changed; +1 (insertion), -1 (deletion)

• Last minute change caused installer not to try and recognize browser language preferences. (install.php)

English and alternate language can both use either a simple string, or an array of strings.
It's a neat technique, isn't it..? But, it implies working from a PHP codebase when you're translating. :-/Willing to bet they won't even bother..?

[Commit revision e775f37]
Author: Nao
Date: Sun, 01 Jun 2014 17:37:37 +0200
Stats: 2 files changed; +21 (insertions), -16 (deletions)

• Fixing installer crash, hopefully elegantly. (install.php, Class-System.php)
• If a language was stored in the session variable, disabling that language from the admin area would cause problems. (Class-System.php)
• Testing requested!