http://www.phpwact.org/php/i18n/utf-8
http://www.scribd.com/doc/940142/utf8-survival

Ciao

However the problem occurs with embedded vars ($a) in strings. Please have a look at the test2.php file I attach here now. It describes the problem I experience. Thanks in advance for your feedback.

Forgot my last comment!!! It's sprintf(). Bloody sprintf(). Deleting previous comment!

I think I've found a workaround:

This is current string to evaluate, that is broken:

$resultstring= sprintf("Connecté sous le nom « $a »");

But this seems to be properly evaluated:

$resultstring= sprintf("Connecté sous le nom « ". $a. " »");

Silly trick but seems that we could, simply, replace all the $a (or $a->whatever) by " . $a . ", and that way, forcing the concatenation... results seem to be properly processed by sprintf/eval. Stupid PHP after all.

My only concern is about the cost of applying that replace (regular expression) to all the strings all the time. Could be too much.

$resultstring= sprintf("Connecté sous le nom « {$a} »");

Idiot PHP. :-D

Ciao

• 1000 strings processed, without the regular expression: 0.032 seconds
• 1000 strings processed, with the regular expression: 0.039 seconds

Difference: 0.007 seconds (21% slower)

• 100000 strings processed, without the regular expression: 3.365 seconds
• 100000 strings processed, with the regular expression: 4.114 seconds

Difference: 0.749 seconds (22% slower)

Note that this is a comparison between the execution of test2.php and test3.php above, processing the same "in-memory" string 1000 and 100000 times.

I guess differences in real world (where strings are "in-file", hence slower access) will be really smaller. More yet, 0.007 seconds for 1000 strings seems to be a viable solution if finally implemented.

Ciao

The grep solution would work out of the box for a small performance cost. With the checker solcution, there's a risk for the translator to forget the check before committing (I know myself ).

In any case, both solution will be better than actual situation.

return preg_replace('/{?(\$a(->\w+)?)}?/', '{\\1}', $temp);

or even

return preg_replace('/{(\$a(->\w+)?)}/', '{\1}}', $temp);

Please include it in moodle/admin with all the other nice testscripts (might be the time to create a folder for them )

I think that we shouldn't make translators life harder here, by forcing them to know about those {} internals at all. IMO, if the times are aceptable, we should grep in code and leave them free from complexities.

Only if times aren't aceptable I'd convert/produce that in the editor.

Just my opinion.

IMO it should be handled from core. The only thing is to measure carefully the cost before doing that. Hopefully, some day, PHP won't bug there, so the workaround will be erased safely.

Ciao

And re PHP bug: it seems that php6 will be UTF-8 compatible, so there's some hope here.

Ciao

Ciao!

1)- apply the patch and leave moodle to process it, leaving languages unmodified.
2)- don't apply the patch, updating all languages and editor to use {} plus sanity checks, leaving moodle unmodified.

My +1 is about to implement 1), apply the patch and forget modifications in langs.

But I'd like to hear some more votes here before doing that.

Ciao

Martin, after some HQ chat about this, Tim detected that that sprintf() has been there since the beginning. See:

http://cvs.moodle.org/moodle/lib/moodlelib.php?view=diff&pathrev=MOODLE_19_STABLE&r1=1.25&r2=1.26

Do you remember any case where it is necessary? It seems that directly eval() the string is enough to perform all the $a(whatever) parsing.

Also, Tim comments about to use one manual solution for translators having the problem as far as it doesn't affect too many strings, instead of preg_replace always the evaled sentence.

• Shows no differences between using sprintf() and not using it.
• Shows that the original preg_replace() isn't valid for strings like «$a» (without spaces).
• Shows that adding the /u (unicode) modifier to the preg_replace() it processes the strings properly.

I any case, things to decide:

1) Erase sprintf() use if we don't need it. HEAD only for now + unit tests. Backported later.
2) Automated vs. manual {} parsing.

Ciao

{$a} workaround still applies.

Is there any alternative to eval() for detecting parse errors?

If eval is really not Unicode-safe, then we may have to resort to writing our own parser to replace $a and $a->xxx in lang strings. Actually, that should be an easy preg_replace. The only thing to be careful about is to know whether we are relying on eval to do anything else for us. I guess it also replaces \" and \$ with " and $ respectively.

http://au2.php.net/manual/en/language.variables.basics.php

Non-breaking space (character \xa0) is a legal character in a variable name, so, if you are insane you could write code like

$user name = "Nicolas Martignoni";
echo 'This is the output of Moodle:<br />';
echo get_string('loggedinas', 'moodle', $user name);

Anyway, that explains why '$a »' does not work as expected. It is looking for a variable called '$a ' (a followed by non-breaking-space) which obviously does not exist.

The correct work-around is to define

$string['loggedinas'] = 'Connecté sous le nom « {$a} »';

That is, use curly braces to separate the variable from the following character, just like you would say

$string['distancerun'] = 'You have run {$a}km.';

to avoid referring to the variable $akm.

So, this is resolve not-a-bug, but translators need to be aware. I'll post in the Languages forum.