RE: [Various implementers] implementation effort for defaults (action-486 and action-489)

Hi Mauricio, all,

 

Well, since we are not trying to stick with what’s in the HTML5 specification anymore, that sounds logical with me.

 

If an ITS tool needs to access them, it can still use a global ITS rule to make them translatable.

 

There is one exception to the list: srcdoc value is un-parsed HTML, so it probably should remain with the attribute translatable by default, and still be marked as ‘special’ and requiring a secondary parsing.

 

cheers,

-yves

 

 

From: Mauricio del Olmo [mailto:mauricio.delolmo@linguaserve.com] 
Sent: Tuesday, April 23, 2013 3:55 AM
To: 'Felix Sasaki'; 'Ankit Srivastava'; 'Dominic Jones'; 'Leroy Finn'; 'Clemens Weins'; 'Karl Fritsche'; 'Mārcis Pinnis'; 'Thomas Ruedesheim'
Cc: public-multilingualweb-lt@w3.org
Subject: RE: [Various implementers] implementation effort for defaults (action-486 and action-489)

 

Hi all.

 

Maybe I’m a bit late about this, but I have some opinion about the “indirectly translatable” tags or attributes mentioned some mails ago.

I mean, the HTML tags or attributes that can have scripts or other languages different from HTML inside (CSS, JavaScrip, VBScript…) that potentially can have inside parts of translatable text. JavaScript instructions like alert(), confirm(), document.write().

 

Form a best practices standpoint, it is not a best practice to have translatable text inside scripts. It is better to have the code internationalized.

I’m using JavaScript as example because I’m more familiar with it.

 

JavaScript inside html content:

JavaScript scripts or functions within the content could not be adequately protected by a CAT tool. In addition, some items may require to be translated or modified, as in the case of variables with language-dependent text, so their use is discouraged. Instead use calls to functions in .js files.

 

JavaScript in js files:

Form field checks, definition of variables and business logic with translatable texts should be avoided.

 

if (min_year <= 400) {

    alert("For this algorithm to work year must be greater than 400");

}

 

var months = new arr("Jan", "Feb", "Mar", "Apr", "May", "Jun", "Jul", "Aug", "Sep", "Oct", "Nov", "Dec");

 

A better strategy would be to define constants that identify the texts and use those references from the JavaScript code. These variables would be declared in another internationalization js file. A version of tis file would exist for each language (eg i18n_de.js, i18n_en.js, i18n_fr.js, i18n_es.js) and would be included based on the navigation language.

 

Inside the internationalization js file i18n_[language].js would be:

var invalid_min_year = "For this algorithm to work year must be greater than 400";

var month_ene = "Jan";

var month_feb = " Feb";

var month_mar = "Mar";

……

 

And in the JavaScript function:

if (min_year <= 400) {

   alert(invalid_min_year);

}

 

var months = new arr(month_ene, month_feb, month_mar, …);

 

Therefore, it is a basic principle of best practices in the internationalization of information systems to isolate the functional code (such as scripts) form the textual content by using variables whose values are properly referenced from the code.

This principle also simplifies code maintenance in multilingual applications. This way, only would be necessary to add new variables in the i18n_[language].js of the master language, translate them to the other available languages and add them at the end of each i18n_[language].js file.

 

If we talk about dynamic languages like JSP, ASP or PHP, the same concept could be applied using an internationalization table in the database to declare the texts of the variables in each language.

 

 

Having in mind all that I have said above, my opinion is that I would left out of the ITS 2.0 HTML 5 defaults all the tags and attributes affected by this (<style>, <script>, on* attributes). I would not say anything about them in our HTML specific defaults, that implies that the ITS 2.0 defaults would be applied over them, and not specific ones.

Ref:  <http://www.w3.org/International/multilingualweb/lt/wiki/HTML5_Defaults> http://www.w3.org/International/multilingualweb/lt/wiki/HTML5_Defaults

 

Cheers.

__________________________________

Mauricio del Olmo Martínez

Dpto. Técnico/I+D+i

Linguaserve Internacionalización de Servicios, S.A.

Tel.: +34 91 761 64 60 ext. 0421
Fax: +34 91 542 89 28 

E-mail:  <mailto:tecnico@linguaserve.com> tecnico@linguaserve.com

www.linguaserve.com <http://www.linguaserve.com/> 

 

«En cumplimiento con lo previsto con los artículos 21 y 22 de la Ley 34/2002, de 11 de julio, de Servicios de la Sociedad de Información y Comercio Electrónico, le informamos que procederemos al archivo y tratamiento de sus datos exclusivamente con fines de promoción de los productos y servicios ofrecidos por LINGUASERVE INTERNACIONALIZACIÓN DE SERVICIOS, S.A. En caso de que Vdes. no deseen que procedamos al archivo y tratamiento de los datos proporcionados, o no deseen recibir comunicaciones comerciales sobre los productos y servicios ofrecidos, comuníquenoslo a clients@linguaserve.com, y su petición será inmediatamente cumplida.»

 

"According to the provisions set forth in articles 21 and 22 of Law 34/2002 of July 11 regarding Information Society and eCommerce Services, we will store and use your personal data with the sole purpose of marketing the products and services offered by LINGUASERVE INTERNACIONALIZACIÓN DE SERVICIOS, S.A. If you do not wish your personal data to be stored and handled, or you do not wish to receive further information regarding products and services offered by our company, please e-mail us to clients@linguaserve.com. Your request will be processed immediately.”

__________________________________

-----Mensaje original-----
De: Felix Sasaki [mailto:fsasaki@w3.org] 
Enviado el: lunes, 22 de abril de 2013 14:13
Para: Ankit Srivastava; Dominic Jones; Leroy Finn; Clemens Weins; Karl Fritsche; Mārcis Pinnis; 'Thomas Ruedesheim'
CC: public-multilingualweb-lt@w3.org
Asunto: Re: [Various implementers] implementation effort for defaults (action-486 and action-489)

 

Dear various implementers again again,

 

I'm not sure if you have seen this thread

 

 <http://lists.w3.org/Archives/Public/public-multilingualweb-lt/2013Apr/thread.html#msg64> http://lists.w3.org/Archives/Public/public-multilingualweb-lt/2013Apr/thread.html#msg64

 

a summary from Yves is here

 <http://lists.w3.org/Archives/Public/public-multilingualweb-lt/2013Apr/0124.html> http://lists.w3.org/Archives/Public/public-multilingualweb-lt/2013Apr/0124.html

and the current thinking here

 <http://lists.w3.org/Archives/Public/public-multilingualweb-lt/2013Apr/0139.html> http://lists.w3.org/Archives/Public/public-multilingualweb-lt/2013Apr/0139.html

 

it would be great to get your input on this. As written in below mail, we want to decide about this during this weeks Wednesday call.

 

Thanks,

 

Felix

 

 

Am 16.04.13 09:48, schrieb Felix Sasaki:

> Dear Ankit, Dom / Leroy, Clemens / Karl, Marcis, Thomas,

> 

> we are currently discussing defaults for HTML5 processing. See the 

> current thinking at

> 

>  <http://www.w3.org/International/multilingualweb/lt/wiki/HTML5_Defaults> http://www.w3.org/International/multilingualweb/lt/wiki/HTML5_Defaults

> 

> With this mail I want to check whether you will have the resources 

> needed for testing the defaults. This seems to be critical for 

> "Translate" and "Elements Within Text", since most of the tests here 

> have already been done. So re-doing the tests with defaults would mean:

> 1) not providing new input files, no need to change these

> 2) provide reference output files

> 3) provide "your" output files

> 

> I am putting Dom / Leroy into the loop as well, for the reference 

> output files.

> 

> The proposed time line would be:

> 

> - Decide on defaults within the next week, that is by 24 April

> - Start testing with defaults before the Bled f2f. Discuss testing 

> issues in Bled

> - Finalize the testing within May.

> 

> Would that work for you timewise? If I don't hear back from you I'd 

> assume that this is OK.

> 

> Note that this topic is important for other implementers as well (e.g. 

> Linguaserve), but we had discussed that already during last week's 

> call and I think we have the commitment already - let me know otherwise.

> 

> Thanks a lot for you help in advance,

> 

> Felix