Localization Workflow/Approach

[Tobin Harris]

Hi there,

WARNING: Long-ish post!

I'm about to undertake an ASP.NET project that requires localisation (2
languages initially, then more).

I have read a little about localization, but have never needed to use it
commercially yet. I'm wandering what the best way to approach localization
is from a technical and also non technical point of view. My first thoughts
are these...

It seems to me that I should make it the clients responsibility to update
and add new language versions. This way, I can concentrate on software
issues, leaving them to worry about translation. The main reason for this is
that I don't want to be dragged into hundreds of language iterations of
"tweak resources - update code - review - tweak more"... I can't see how I
can achieve this using the standard resource file approach, my client won't
be able to work with these in their raw format, and there is no instant
feedback cycle to check that things look ok in the app.

A hopefully better option I need to research would be to build special tools
to allow the client to tweak language resources themselves, and see the
changes at run time in the ASP.NET pages. This will probably mean putting
string resources in a database and looking them up dynamically at runtime
(with some caching scheme of course!)

From a developers point of view, a "token" would be assigned to each control
(in the Tag or something ). For example, a "Yes" button might just have the
lookup token "Buttons.Yes". The client can use a tool to lookup this token
and then set the various language strings for it ("Yes", "Ja" or "Ci") for
example. They can then view the changes live, by selecting the appropriate
language.

This raises the question of how the client can know which token corresponds
to which UI control. This could be done by having a few different browse
modes:

- ResourceStringOnly: this is the default mode that is used in the live app.
A button might just show the text "Yes"
- TokensOnly: shows only the token such as "Buttons.Yes" rather than the
lanugage specific string.
- TokensAndResourceStrings: showing both the code and the string for the
currently selected language. E.g "[Buttons.Yes] Yes"

Using TokensOnly, they can see the token that they need to lookup to make a
correction/ammendment.

Now, assuming all this works and can be made performant, I'll be in a
position where the client can look after languages, and I can look after
coding, which hopefully will save me the anticipated pain of having to spend
time with the client worrying about language issues.

I realise there are other issues that I haven't yet considered, such as
string sizes, numerical formatting etc, but if this idea is ok then I can
move on to consider those aspects.

Are my goals naive? Is the solution naive!? Are there tried and tested
methods and tools that just work! Am I re-inventing the wheel? Any thoughts
would be *really* appreciated.

Just in case you're wondering, I'm thinking that 2 things will allow me to
accommodate different string sizes without too much pain:

1 - Keep screens simple, light and roomy
2- Intelligent use or CSS.
3 - We also need to follow W3C accessibility guidelines (priority 1 at
least), and I'm hoping that a simple design will benefit these also.

Hope all that made sense!?

Thanks in advance

Tobin

[Karl Seguin]

Tobin:
I wrote a couple in-depth tutorials w/samples and reusable controls I think
you'll find very handy:
http://www.openmymind.net/index.aspx?documentId=3
http://www.openmymind.net/index.aspx?documentId=4

it uses non-compiled XML files so that your clients will be able to modify
them (you could even built a front-end (lemme know if you do so))...

Karl

--
MY ASP.Net tutorials
http://www.openmymind.net/ - New and Improved (yes, the popup is annoying)
http://www.openmymind.net/faq.aspx - unofficial newsgroup FAQ (more to
come!)
"Tobin Harris" <tobin@_do_not_spam_tobinharris.com> wrote in message
news:42**********************@news.zen.co.uk...

Hi there,

WARNING: Long-ish post!

I'm about to undertake an ASP.NET project that requires localisation (2
languages initially, then more).

I have read a little about localization, but have never needed to use it
commercially yet. I'm wandering what the best way to approach localization
is from a technical and also non technical point of view. My first thoughts are these...

It seems to me that I should make it the clients responsibility to update
and add new language versions. This way, I can concentrate on software
issues, leaving them to worry about translation. The main reason for this is that I don't want to be dragged into hundreds of language iterations of
"tweak resources - update code - review - tweak more"... I can't see how I can achieve this using the standard resource file approach, my client won't be able to work with these in their raw format, and there is no instant
feedback cycle to check that things look ok in the app.

A hopefully better option I need to research would be to build special tools to allow the client to tweak language resources themselves, and see the
changes at run time in the ASP.NET pages. This will probably mean putting
string resources in a database and looking them up dynamically at runtime
(with some caching scheme of course!)

From a developers point of view, a "token" would be assigned to each control (in the Tag or something ). For example, a "Yes" button might just have the lookup token "Buttons.Yes". The client can use a tool to lookup this token
and then set the various language strings for it ("Yes", "Ja" or "Ci") for
example. They can then view the changes live, by selecting the appropriate
language.

This raises the question of how the client can know which token corresponds to which UI control. This could be done by having a few different browse
modes:

- ResourceStringOnly: this is the default mode that is used in the live app. A button might just show the text "Yes"
- TokensOnly: shows only the token such as "Buttons.Yes" rather than the
lanugage specific string.
- TokensAndResourceStrings: showing both the code and the string for the
currently selected language. E.g "[Buttons.Yes] Yes"

Using TokensOnly, they can see the token that they need to lookup to make a correction/ammendment.

Now, assuming all this works and can be made performant, I'll be in a
position where the client can look after languages, and I can look after
coding, which hopefully will save me the anticipated pain of having to spend time with the client worrying about language issues.

I realise there are other issues that I haven't yet considered, such as
string sizes, numerical formatting etc, but if this idea is ok then I can
move on to consider those aspects.

Are my goals naive? Is the solution naive!? Are there tried and tested
methods and tools that just work! Am I re-inventing the wheel? Any thoughts would be *really* appreciated.

Just in case you're wondering, I'm thinking that 2 things will allow me to
accommodate different string sizes without too much pain:

1 - Keep screens simple, light and roomy
2- Intelligent use or CSS.
3 - We also need to follow W3C accessibility guidelines (priority 1 at
least), and I'm hoping that a simple design will benefit these also.

Hope all that made sense!?

Thanks in advance

Tobin

[Tobin Harris]

Hi Karl,

Thanks *very* much for those resources, they're great. You've nicely
summarised the concepts in play, and attacked some really important issues.
Have many people used your appraoch? Is is credible ;-) I need to download
the app and have a better look, but it certainly looks like you're
attempting to address all the problems I'm anticipating.

The URL Rewriting looks like a flexible way of passing prefered culture into
the app without needing the session. It took me a minute to understand what
was going on here, I've never seen RewritePath before, but it's very useful
thankyou!

I was wondering if there any reason why you don't recommend keeping all
string resources in a database as opposed to an XML file?

What you raise about having multiple languages for data items is a good
point. I'd not thought of that yet. It's such a shame though - normalising
like this seems to complicate things so much! I imagine you'll get quite a
table explosion if there are lots of entities that are locale specific. I
agree that it's better than having a repeating group (one column per
language). Have you tried any other database approaches other than that
shown in part 2?

Thanks

Tobin

[Karl Seguin]

Tobin:
A part of this approach stems from my own experience and another from the
CommunityServerForums which were developed by some fine microsoft regional
directors and mvps so, in my humble opinion, it's quite credible.

The XML file has the advantage of not really needing a programmed interface
to manipulate...just open in textpad and voila...you could do the same with
the database, but it wouldn't be as simple for translators whom likely never
used enterprise manager (you could of course import/export it to excel or
something)...anyways, there's no technical reason to prefer one over the
other...if you have a large amount of data, the database might be better
'cuz you can more easily customize it to do a lazy-load...that is cache the
data which is used frequently and hit the database for that which isn't (ur
typical 20/80 rule where 20% of stuff causes 80% of work).

These are the only two data models I've used. If you're 100% sure you won't
need to support additional languages in the future have column names with a
language prefix or something isn't too bad...it's when you start to add
additional languages that things get ugly. For database, I stick with the
"normalize 'til it hurts; denormalize 'til it works"...

Karl

--
MY ASP.Net tutorials
http://www.openmymind.net/ - New and Improved (yes, the popup is annoying)
http://www.openmymind.net/faq.aspx - unofficial newsgroup FAQ (more to
come!)
"Tobin Harris" <tobin@_do_not_spam_tobinharris.com> wrote in message
news:42***********************@news.zen.co.uk...

Hi Karl,

Thanks *very* much for those resources, they're great. You've nicely
summarised the concepts in play, and attacked some really important issues. Have many people used your appraoch? Is is credible ;-) I need to download
the app and have a better look, but it certainly looks like you're
attempting to address all the problems I'm anticipating.

The URL Rewriting looks like a flexible way of passing prefered culture into the app without needing the session. It took me a minute to understand what was going on here, I've never seen RewritePath before, but it's very useful thankyou!

I was wondering if there any reason why you don't recommend keeping all
string resources in a database as opposed to an XML file?

What you raise about having multiple languages for data items is a good
point. I'd not thought of that yet. It's such a shame though - normalising
like this seems to complicate things so much! I imagine you'll get quite a
table explosion if there are lots of entities that are locale specific. I
agree that it's better than having a repeating group (one column per
language). Have you tried any other database approaches other than that
shown in part 2?

Thanks

Tobin

[Tobin Harris]

"Karl Seguin" <karl REMOVE @ REMOVE openmymind REMOVEMETOO . ANDME net>
wrote in message news:eA**************@tk2msftngp13.phx.gbl...

A part of this approach stems from my own experience and another from the
CommunityServerForums which were developed by some fine microsoft regional
directors and mvps so, in my humble opinion, it's quite credible.
Thanks, I'll trust you ;-)
The XML file has the advantage of not really needing a programmed
interface
to manipulate...just open in textpad and voila...you could do the same
with
the database, but it wouldn't be as simple for translators whom likely
never
used enterprise manager (you could of course import/export it to excel or
something)...anyways, there's no technical reason to prefer one over the
other...if you have a large amount of data, the database might be better
I was thinking of a writing a simple web admin tool that would help with
this, so that they could use a web interface to set up languages.
Interestingly, the Microsoft Enterprise Localization Toolkit seems to have
something like this, however it's limited to SQL Server 8-(
These are the only two data models I've used. If you're 100% sure you
won't
need to support additional languages in the future have column names with
a
language prefix or something isn't too bad...it's when you start to add
additional languages that things get ugly. For database, I stick with the
"normalize 'til it hurts; denormalize 'til it works"...
I'll agree with you on that one! I was thinking of other ways for product
data, but in the end I decided that your way is best!

Thanks for your help.
Karl

--
MY ASP.Net tutorials
http://www.openmymind.net/ - New and Improved (yes, the popup is annoying)
http://www.openmymind.net/faq.aspx - unofficial newsgroup FAQ (more to
come!)
"Tobin Harris" <tobin@_do_not_spam_tobinharris.com> wrote in message
news:42***********************@news.zen.co.uk...

Hi Karl,

Thanks *very* much for those resources, they're great. You've nicely
summarised the concepts in play, and attacked some really important

issues.

Have many people used your appraoch? Is is credible ;-) I need to
download
the app and have a better look, but it certainly looks like you're
attempting to address all the problems I'm anticipating.

The URL Rewriting looks like a flexible way of passing prefered culture

into

the app without needing the session. It took me a minute to understand

what

was going on here, I've never seen RewritePath before, but it's very

useful

thankyou!

I was wondering if there any reason why you don't recommend keeping all
string resources in a database as opposed to an XML file?

What you raise about having multiple languages for data items is a good
point. I'd not thought of that yet. It's such a shame though -
normalising
like this seems to complicate things so much! I imagine you'll get quite
a
table explosion if there are lots of entities that are locale specific. I
agree that it's better than having a repeating group (one column per
language). Have you tried any other database approaches other than that
shown in part 2?

Thanks

Tobin