Steps to submit a language file

4 views
Skip to first unread message

Aaron Newton

unread,
Feb 15, 2009, 9:55:22 PM2/15/09
to MooTools Lang
1) verify that we don't already have that language file:
http://github.com/anutron/mootools-more/tree/master/Source/Localization

2) if we already have it, review it and ensure that we have all the
parts we need. Compare it to the English version, which will always be
complete.

3) create a new version and post about it here. The easiest thing to
do is to create a gist for it on github: http://gist.github.com/ and
then post the link. If you are familiar with git, you can branch the
tree in the link from #1 and commit your new file.

4) Ensure your name is in the header of the file. This will help us if
we need to come back and ask questions here about your work and it's
also nice to give credit where it is due.

Lennart

unread,
Feb 16, 2009, 7:00:41 AM2/16/09
to MooTools Lang
New Dutch translation (nlNL):

http://gist.github.com/65137

websam

unread,
Feb 17, 2009, 3:39:49 PM2/17/09
to MooTools Lang
New Danish date file :

http://gist.github.com/65956

Aaron Newton

unread,
Feb 17, 2009, 4:17:50 PM2/17/09
to mootoo...@googlegroups.com
Hi gang,

I haven't posted a reply here in the last day or so, but keep it up. This is all good stuff. I'll be pulling this into -more today or tomorrow.

websam

unread,
Feb 17, 2009, 4:40:39 PM2/17/09
to MooTools Lang
And here you have the FormValidator file :

http://gist.github.com/65997

Carl Holmberg

unread,
Feb 24, 2009, 6:03:39 AM2/24/09
to MooTools Lang
Hi, I've posted a Swedish translation here: http://gist.github.com/69501.
I hope it is okay!

I have some comments for the FormValidator file...

numeric :
In Sweden we use a comma for our decimals. I added a note that you
have to use dots instead. Is this correct or will it allow for other
decimal characters?

alpha:
Are the constraints to a-z also valid for other languages with other
characters in their alfabets? I left "(a-z)" i my translated string,
but if it is a textfield it should, in Sweidsh, be "(a-ö)".

email:
Should the example be localized? The Swedish translation,
"fredrik@domän.se", isn't ideal because it contains non ASCII
characters. I left the original example.

reqChkByNode:
I'm not sure how to translate this because "items" doesn't translate
well to Swedish without a specific context. Perhaps someone else has a
good translation for this – I'm not sure about the current context.
Right now it is translated as "nothing is selected" which probably is
adequate.

reqChkByName:
A problem here (also in English) is that "a" or in Swedish "en" could
be "an" (or in Swedish "ett") depending on the label.


I think it's great that Mootools is localized when there is a textual
output and thanks for all your great work Aaron!

/Carl

Carl Holmberg

unread,
Feb 24, 2009, 6:16:09 AM2/24/09
to MooTools Lang
Just a nother note...

AM and PM is hardly used at all in Sweden. "fm/em" which I have given
in the translated strings are sometimes used in the same way as AM/PM
but not that often when a digital clock is shown. I.e. in Mac OS X you
can't even choose to show "fm/em" when a 12-hour clock is selected and
the system is localized to Sweden. It's permanently greyed out.
Perhaps an option to default to 24-hour clock would be a good idea...
or a format-string like for dates, i.e. "h:i A" in English and "H:i"
in Swedish (PHP-date format characters).

Aaron Newton

unread,
Feb 24, 2009, 1:18:54 PM2/24/09
to mootoo...@googlegroups.com
1) Thanks for translating!

2) It's important to remember that these validators validate data that gets sent to a server. A validator's messaging needs to be localized, but the validation itself does not change. If you were authoring a form for a swedish audience that expects to enter numbers as 1.000,00 instead of 1,000.00, then the included validator *would not work* and you would need to write a *new* validator. Having the validator change because the user is accustomed to a different convention wouldn't affect the server, which is still expecting numbers as 1,000.00. This is just one such example. The point is that the validator doesn't change here, just the translation of it's error.

numeric :
In Sweden we use a comma for our decimals. I added a note that you
have to use dots instead. Is this correct or will it allow for other
decimal characters?

see above 
 
alpha:
Are the constraints to a-z also valid for other languages with other
characters in their alfabets? I left "(a-z)" i my translated string,
but if it is a textfield it should, in Sweidsh, be "(a-ö)".

Again, the validator doesn't change here. If you want your form to accept extended ascii, then someone needs to author a validate-extended-alpha validator or something.
 
email:
Should the example be localized? The Swedish translation,
"fredrik@domän.se", isn't ideal because it contains non ASCII
characters. I left the original example.

Same deal. The current example does not allow extended chars.
 
reqChkByNode:
I'm not sure how to translate this because "items" doesn't translate
well to Swedish without a specific context. Perhaps someone else has a
good translation for this – I'm not sure about the current context.
Right now it is translated as "nothing is selected" which probably is
adequate.

Sounds reasonable.
 
reqChkByName:
A problem here (also in English) is that "a" or in Swedish "en" could
be "an" (or in Swedish "ett") depending on the label.

You might do the equivalent of:

Please select a(n) {label}.

I've actually just changed the english to this.
As pointed out elsewhere, this am/pm stuff isn't used by any of the classes. It's there so that you can retrieve the property if you like, but if your culture typically uses 24 hour cycles then you could just not reference the property. It's not referenced in any of the validators, only in the Date formatters.

-Aaron 
Reply all
Reply to author
Forward
This conversation is locked
You cannot reply and perform actions on locked conversations.
0 new messages