## Using AMOS tool for language pack translation

### Reply on "fixes needed in langconfig.php"

Reply on "fixes needed in langconfig.php"

Hi, David.

In Russian there is tradition not to separate thousands or to separate them with space. So, for a long time thousands separator was left empty, leading to discussed problem.

As for now i cannot commit space or empty string using AMOS. The only way is to commit any other string and then commit empty string. But i'm not shure that i can commit single space charcter this way. And please check wether your checker-script differs NOT SET string and string SET TO EMPTY.

The other way is to commit &#32; or &#nbsp; as thousands separator, but i'm afraid that such substitution will not work correctly in any code

Re: Reply on "fixes needed in langconfig.php"

I added \$string['thousandssep'] = '.' to langconfig.php, and committed in CVS. David may wanto to check if everything is better for 1.9 lang pack.

Re: Reply on "fixes needed in langconfig.php"
Thanks Andrea, I can confirm Italian is not reported any more by the script.
Re: Reply on "fixes needed in langconfig.php"

Hello David

I checked the German settings

decsep ist es to ',' and thousandsep set to '.' for 'de'. That seems to be correct.  But your file reported something different:

Invalid decsep and/or thousandssep in German {de} at 1.9!!

Added entries to sub languages.

German (Personal) {de_du} at 1.9!! 2.0!! 2.1!! 2.2!! 2.3dev!!
German - Kids {de_kids} at 2.0! 2.1! 2.2! 2.3dev!

Re: Reply on "fixes needed in langconfig.php"
Hi Ralf. I just did a very fresh checkout of de_utf8 from CVS and the script is right - the string thousandsep is not defined in langconfig.php there - see http://cvs.moodle.org/lang/de_utf8/langconfig.php?view=markup
Re: Reply on "fixes needed in langconfig.php"

Hi David

can reproduce it in CV, but not in AMOS. The '.' for thousandsep is set. Can you please check it again in AMOS also.

Re: Reply on "fixes needed in langconfig.php"
Of course I did check it. The string is missing from AMOS, too - see http://lang.moodle.org/local/amos/view.php?t=1327820182&v=1900&l=de&c=langconfig&s=&d=
Re: Reply on "fixes needed in langconfig.php"

Now I got the point. Its 1.9 version only.

Re: Reply on "fixes needed in langconfig.php"

Yes, that's what the line

Invalid decsep and/or thousandssep in German {de} at 1.9!!


is trying to say. And that's why I was referring to CVS. Since 2.0, strings are not in CVS any more. I am happy it's clear now.

Re: Reply on "fixes needed in langconfig.php"

In french too, the thousand separator is special. It should be a non-breaking space (specifically a non-breaking thin space ).

David, can you confirm that this setting is OK ? Til now it didn't break anything.

Re: Reply on "fixes needed in langconfig.php"

да I can understand your issue. In Czech, it is also more common to use spaces as the separator - thin spaces to be typographically precise. In WWW environments, the non-breaking space is usually used for for obvious reasons and AMOS does accept it. The actual input method depends on your keyboard configuration. I am GNU/Linux user so I use Compose+Space+Space to produce 0xC2 0xA0 bytes that represent U+00A0 in UTF-8 encoding.

But... Although non-breakable space would work fine for rendering numbers, yet another problem can emerge. The numerical question type uses the defined thousands separator when parsing and analysing students' responses, too. I did not test it but I am a bit afraid that if the non-breaking space is defined as the separator and students use the ordinary space, Moodle might consider their response as incorrect. Again, I did not test it and chances are that the question type authors were aware of this and the code copes with the situation well. If anybody can confirm it works or not, it would be very useful. If it does not work, people can easily face the situation that the student's response "10 000 000" (using ordinary spaces) is not the same as the correct "10 000 000" one (using non-breaking spaces).

So therefore I decided to use the comma as the separator for Czech even if it is less common (but still acceptable).

And yes, I think we will have to tweak the translator UI a bit and provide a way how we could declare that the translation should be defined as an empty string. We already had an issue with it - you may remember those delta size strings issue in TinyMCE, though there is a workaround of using zeros.