Wow, Henrik. Your post covers a lot of ground.


----- Original Message -----
From: Henrik Rützou <hr@xxxxxxxxxxxx>
To: Web Enabling the IBM i (AS/400 and iSeries) <web400@xxxxxxxxxxxx>
Cc:
Sent: Wednesday, February 6, 2013 9:44 AM
Subject: Re: [WEB400] Web Application Internalization Best Practices

Hi Paul,

Translations can be made in javascript or in CSS = in the browser, however
it requires big javascript, CSS or JSON files to support every string of
metadata.

And Internalization isn't done by that, you also need to define date and
time formats, decimal formats and have both UNICODE to support all
characters and RTL support to support arabic, hebrew, persian and urdu.

In practice you will need some server side code, tables and some collection
routines in the framework because it is not a programmer’s job to translate
a system into different languages.

Many Client Frameworks such as EXT JS and jQuery comes with a lot of
languages, but still you are on your own with the metadata the server
framework generates/uses or you generated code contains.

Putting these metadata into javascript, CSS or JSON files represents a
development and change management nightmare especially if you use
techniques like seen in jQuery where you directly refer to a JSON entity
(or a CSS class) like:

< a>class="name I18N">menu.products.title</a

< div class="desc I18N">menu.products.desc</div

The big problem is in both JSON and CSS is what if the entity or class
isn’t there? You get nothing! It is much easier to code on the server side
like below and it is much easier for a user to say I run in French but get
“Our Products” on my screen than trying to explain that he gets “nothing”
on his screen.

htmlNode('a':'class="name"':i18n('Our Products':'en'));

htmlNode('div':'class="desc"':i18n(proddesc:'en'));

and thereby let the server return that text in a specific language because
this technique

1. Return the original value if not defined in the receiving language

2. Is much more readable in the server side code

3. Can catch undefined translation in a table

4. Can be Google translated in a split second

5. Can be left for a professional translator to finish

6. Also can include translation referential data from tables that also are
considered metadata

7. There is no reload of classes

However this is not an either or technique, I use EXT JS standard
translations that translates all text strings in their components, I use
javascript to translate all common used phrases (such as "log off") in my
own javascript components and then I use server side translations for
metadata and general property settings (such as date formats) in the EXT JS
components.

All data between the server and client I always pass in JSON/UTF-8 and all
numeric values and dates are always passed in ISO format and converted on
the client side according to the selected language settings and on the
server side according to the DB field definition.

To define and translate into a new language I put the system in collective
mode, defines the new language in a table, log in on the new language and
run through the programs and the system will collect and create an entry
for each sentence used in the UI without translation in the new language
but with from/to language properties.

This takes about 15 minutes.

Afterwards I run a simple HTTPAPI program that makes a raw Google
translation of all the collected sentences to the new language and I may
have a 95-98% correct translation and the design ensures that the
translation can be 100% and it is low cost, fast, automatically expandable
and final translations can be delegated to people without programming
experience.

You should also consider that we need a technique that in the simplest way
can be reused across all devices in a Multi-Channel Delivery environment.

To really build a system for international use I don’t think that many know
how big and multi spread a job it is. It is not done with a little CSS, it
has to be built into the system in a very low level and just the small
number of online programs powerEXT Framework generates of descriptive
metadata results in approx. 7,000 translations that covers 8 languages
where 4,000 comes from server side translations and 3,000 comes from client
side translations even though my translations aren’t 100% yet – still need
some passing of text to the I18N routine and still need some work around
automatically recalculating column width in grids when a language changes,
I think that I have been around most technical tasks and many of the 50
subprocedures that has been developed to support my framework (excluding
the 100+ general Core subprocedures) uses I18N support internally.

Finally, besides translating metadata to other languages in the UI, there
is the whole question about Quick Tips and Help Text that in a big system
will be the most expensive area of translation.

As an Amazon Associate we earn from qualifying purchases.

This thread ...

Replies:

Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].

Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.