Getting started with translations: FormValidator and Date

[Aaron Newton]

Greetings!

I must admit I'm a little overwhelmed with how fast this group took
off. It's very exciting to see so many of you interested in being
involved.

So let's dig in. MooTools -more (the official plugins repository) is
nearing its next release date. Currently the library contains two
items that output text for the user - FormValidator and Date. We may
be adding additional items in the future, but for now, these are the
only two.

Both of these came from my repository (http://www.clientcide.com/js).
There the files already had the ability to be translated and I had
numerous awesome people (some already in this group) send in
translations which I published. Some of these are incomplete - we have
added new items that need translating and the content sent in months
ago doesn't include these.

You can see the translations currently available here:

http://github.com/anutron/mootools-more/tree/master/Source/Localization

You'll see we have files for numerous languages, but not all of them
are complete. The only two complete language files are
Date.English.US.js and FormValidator.English.js (because we authored
them). What we need is for you to help us translate these into
whatever languages you are fluent in.

Let's look at one of these files, Date.English.US.js:
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
/*
Script: Date.English.US.js
Date messages for US English.

License:
MIT-style license.

*/

MooTools.lang.set('usENG', 'Date', {

months: ['January', 'February', 'March', 'April', 'May', 'June',
'July', 'August', 'September', 'October', 'November', 'December'],
days: ['Sunday', 'Monday', 'Tuesday', 'Wednesday', 'Thursday',
'Friday', 'Saturday'],
//culture's date order: MM/DD/YYYY
dateOrder: ['month', 'date', 'year', '/'],
AM: 'AM',
PM: 'PM',

/* Date.Extras */
getOrdinal: function(dayOfMonth){
//1st, 2nd, 3rd, etc.
return (dayOfMonth > 3 && dayOfMonth < 21) ? 'th' : ['th', 'st',
'nd', 'rd', 'th'][Math.min(dayOfMonth % 10, 4)];
},

lessThanMinuteAgo: 'less than a minute ago',
minuteAgo: 'about a minute ago',
minutesAgo: '{delta} minutes ago',
hourAgo: 'about an hour ago',
hoursAgo: 'about {delta} hours ago',
dayAgo: '1 day ago',
daysAgo: '{delta} days ago',
lessThanMinuteUntil: 'less than a minute from now',
minuteUntil: 'about a minute from now',
minutesUntil: '{delta} minutes from now',
hourUntil: 'about an hour from now',
hoursUntil: 'about {delta} hours from now',
dayUntil: '1 day from now',
daysUntil: '{delta} days from now'

});
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Most of this is pretty straight forward (hopefully). There are a few
items that are a little esoteric. For instance, 'dateOrder' is used to
determine how the culture orders the date (MM/DD/YYYY in the US, DD/MM/
YYYY in most of Europe).

In some of the items there are variables that get substituted. For
instance 'daysUntil' has '{delta} days from now' and obviously {delta}
is going to be a number ('12 days from now').

There is also a concept of language cascading. Let's look at
Date.English.GB.js:
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
/*
Script: Date.English.GB.js
Date messages for British English.

License:
MIT-style license.

*/

MooTools.lang.set('gbENG', 'Date', {

dateOrder: ['date', 'month', 'year', '/'],
cascades: ['usENG']

});
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

This file gives a different dateOrder (the European style) but then
sets a cascade to the US English settings. This is because Great
Britain uses a different date order, but the rest of the values are
identical to the US English ones. Cascades are an array of other
language ids so that if a language is missing a value, the first item
in the array will be checked for that value. If not found there
either, then the second one and so on. By default, all of the
languages cascade to English as these are the files we know at least
have a value. If you're working on a language that is close to another
language, you might cascade it first to that other language and then
to English. If you have two nearly identical languages with only one
or two differences, you can describe the difference in one file and
cascade it to the other.

Your job is to look and see if we already have a date file for the
language(s) you know. If we do, see if it's complete by checking it
against the English version. If not, add the missing content. If we
don't have a language file for the one you know, then create it.

To send it in you have two options. The preferred option would be for
you to fork it on github and add your new language file(s) and then
send me (anutron on github) a pull request. Alternatively, if you
aren't familiar with git, you can just paste your files into a new
thread here on these forums and we'll pick them up. If you're
concerned with encoding (if your language requires an encoding that
you think the forums might mangle) you can email it to me - (anutron
[at] g m a i l <dot> com). If you do email it, post it here anyway.

Thanks again for stepping up to help out. This is most appreciated.

Aaron & the MooTools Team

[Can HANHAN]

In Turkish locale settings thousand separator is . (dot) and decimal separator is , (comma). 

It does not change in Javascript (Dot is still decimal seperator) but there will be any changes due to number format localizations?

Regards,

Can HANHAN
w: http://www.finarfin.net

[Can HANHAN]

And also is it possible for us to add some special chars as alpha chars?

For example: In Turkish we also have, ş (s with dot under),  ç (c with dot under), ı (i without dot), ö (o with two-dots), ü (u with two-dots) and uppercases of there with a bonus one  İ (I with dot).

  

Regards,

Can HANHAN
w: http://www.finarfin.net

[Aaron Newton]

"In Turkish locale settings thousand separator is . (dot) and decimal separator is , (comma). 

It does not change in Javascript (Dot is still decimal seperator) but there will be any changes due to number format localizations?"

None of our text outputs currently output values that use either dots or commas (I think). I'm not sure if I'm answering this correctly, but I think that anywhere we need to represent a number in our translations that needs a comma or a dot we could, in theory, allow those punctuations to be localized as well...

And also is it possible for us to add some special chars as alpha chars?

For example: In Turkish we also have, ş (s with dot under),  ç (c with dot under), ı (i without dot), ö (o with two-dots), ü (u with two-dots) and uppercases of there with a bonus one  İ (I with dot).

Yes, you can add these, but it would be best if you could use the ascii codes such as these:

http://www.ascii.cl/htmlcodes.htm

so  ç is &ccedil; or &#231;

-Aaron

[Can HANHAN]

Javascript does not use localization in default. So for commas replace is needed. Otherwise dots will be decimal seperator. They will not output but, they will input. So I'm asking because of users may enter commas, instead of dots in text boxes.

Also regexp is used for validation but the problem is special Turkish chars are not included in a-zA-Z. So you should specify them separately.

The pattern you use: (/^[a-zA-Z]+$/)

Regards,

Can HANHAN
w: http://www.finarfin.net

2009/2/15 Aaron Newton <anu...@gmail.com>

[Aaron Newton]

Yes, ok, the validators need tweaking for some languages. We'll have to work on a way to conditionally evaluate the validators based on this. Stay tuned.

In this way you can conditionally 

2009/2/15 Can HANHAN <can.h...@gmail.com>

[Aaron Newton]

woops... didn't mean to include that last sentence fragment. I had started writing something else and then removed it...

2009/2/15 Aaron Newton <anu...@gmail.com>

[Can HANHAN]

Overriding methods for validation maybe a good idea as a fix. We may write these to localization files:

  FormValidator.validators['validate-alpha'].test = function(element){
      return FormValidator.getValidator('IsEmpty').test(element) ||  (/^[a-zA-Z\ascii_codes_for_turkish_chars]+$/).test(element.get('value'));


And same for numeric or decimal validators.

[fabiomcosta]

Aaron, could you tell me if you received my pull request?
I translated formValidator and Date for Portuguese-BR, but i havent
used git before so im a little confused on how to use it.

On Feb 15, 5:44 pm, Can HANHAN <can.han...@gmail.com> wrote:
> Overriding methods for validation maybe a good idea as a fix. We may write
> these to localization files:
>
>   FormValidator.validators['validate-alpha'].test = function(element){
>       return FormValidator.getValidator('IsEmpty').test(element) ||
> (/^[a-zA-Z\ascii_codes_for_turkish_chars]+$/).test(element.get('value'));
>
> And same for numeric or decimal validators.
>
> Regards,
>
> Can HANHAN
> w:http://www.finarfin.net
>

> 2009/2/15 Aaron Newton <anut...@gmail.com>

>
> > woops... didn't mean to include that last sentence fragment. I had started
> > writing something else and then removed it...
>

> > 2009/2/15 Aaron Newton <anut...@gmail.com>

>
> >> Yes, ok, the validators need tweaking for some languages. We'll have to
> >> work on a way to conditionally evaluate the validators based on this. Stay
> >> tuned.
> >> In this way you can conditionally
>

> >> 2009/2/15 Can HANHAN <can.han...@gmail.com>

>
> >> Javascript does not use localization in default. So for commas replace is
> >>> needed. Otherwise dots will be decimal seperator. They will not output but,
> >>> they will input. So I'm asking because of users may enter commas, instead of
> >>> dots in text boxes.
>
> >>> Also regexp is used for validation but the problem is special Turkish
> >>> chars are not included in a-zA-Z. So you should specify them separately.
> >>> The pattern you use: (/^[a-zA-Z]+$/)
>
> >>> Regards,
>
> >>> Can HANHAN
> >>> w:http://www.finarfin.net
>

> >>> 2009/2/15 Aaron Newton <anut...@gmail.com>

[Aaron Newton]

I just sent you a message through github. Basically you need to commit your changes and then push them to github. I'll add a new note for everyone on how to do this with git.

2009/2/15 fabiomcosta <fabio...@gmail.com>

[electronbender]

Macedonian has the . (dot) and comma (,) thing as well.. In fact most
of the Balcan countries here use it.

[Aaron Newton]

Would someone like to author a set of numeric validators that swap the dots and commas where they apply? These would get their own namespace like, validate-number would be validate-number-commaswap or something.

2009/2/19 electronbender <ognen.p...@gmail.com>

[Fábio Costa]

can't it just be done with two constants at the formValidator Localization file?
Like:
..
decimalSeparator: ',',
numberSeparator: '.'
...
something like that, and of course at the validation it would use the corresponding values.
In Brazil numbers are written like: 100.000,00
and i know that in some other places numbers are written: 100,000.00
I don't know any other type of writting them.

Fábio Miranda Costa
Engenheiro de Computação
http://meiocodigo.com

2009/2/19 Aaron Newton <anu...@gmail.com>

[Aaron Newton]

The problem is not one of localization but validation. Let's say you had a form that you validate and you allow people to change the language they see when errors occur. Your server code is Java or PHP or Python or whatever and it is expecting a value that looks like "1,000.00" and it interprets this as "1000.00". The user selects a different language, but your your server code is still expecting the decimal to mean the end of the integers and the beginning of the decimals.

What the error reads as is something that needs to be localized, but the data should not.

2009/2/19 Fábio Costa <fabio...@gmail.com>

[Nicolas Sorosac]

Then why don't we just send the locale used with the rest of the form? (e.g. auto-created hidden input) so that the server-side script knows what locale to use?

In my opinion, people looking for localization both client-side and server-side should use a powerful framework on both sides. 

Anybody using mootools for complex applications (which is what we are talking about) should use something like Zend Framework (PHP example, but I am sure other frameworks also include data localization).

That way, processing localized data is very simplistic (with localized-data convertion, etc.)

2009/2/20 Aaron Newton <anu...@gmail.com>

[Aaron Newton]

2009/2/20 Nicolas Sorosac <nicolas...@gmail.com>

Then why don't we just send the locale used with the rest of the form? (e.g. auto-created hidden input) so that the server-side script knows what locale to use?

This to me is something that an application should decide to do on its own. There's already an event they can monitor (MooTools.lang.addEvent('onLangChange', ...)) so if YOU want to submit that data you can. If your application wants to swap the validators for a specific language, that's something you can do, but that implies a server-side logic (that can know the difference) that I don't think should be inherent in our form validator.

 

In my opinion, people looking for localization both client-side and server-side should use a powerful framework on both sides. 

Anybody using mootools for complex applications (which is what we are talking about) should use something like Zend Framework (PHP example, but I am sure other frameworks also include data localization).

That way, processing localized data is very simplistic (with localized-data convertion, etc.)

I agree that there should be parity with the client-side validation and the server side validation, but it's not something that happens without a conscious effort. One of the benefits of the FormValidator in MooTools -more is that you can author custom validators (and overwrite validators). This means that people using it can customize it to meet the needs of their validation. Ideally, one would author validators on the server side and then transform those into validators for the client (i.e. your PHP/Java/Ruby/etc spits out JavaScript for each validator you author on the server side). But this kind of design is not something that we should require to use our validators or our language localization. Neither is the design pattern that your server should switch its expectations based on the user's language needs. If you want to support that, our library allows you to do so, but it's not inherent in our design.

Aaron

[Nicolas Sorosac]

That's what I was trying to say but, even though it was clear in my mind, I wasn't able to express it. So, thanks for reading my mind :)

2009/2/20 Aaron Newton <anu...@gmail.com>