multilingual application
Michiel Rapati-Kekkonen
Someone from abroad might be interested in my application. Ha, new
perspectives.
The user interface's language, now, is Dutch.
I want to translate all that is Dutch into English.
I made a routine that is able to collect all MsgBoxes in my code and distill
the Prompt part, Title part, whatever.
So I could store them in a table. And put the translation in the field next
to it.
But
many of the Messages are a combination of text with variables.
e.g.
MsgBox "De " & strNum & " de beste, die " & myrsB("strDing") & " vindt,
krijgt een " & myrsV("strPresent"), vbInformation, "Zondagse opgave"
Is there a way to store such messages
so that the variables will work again locally, when MsgBox reads the message
(or the translation) from a table?
(To store only the text parts and let the variables in loco will not always
produce natural results, since every language has it's own preferences for
word order.)
Asking for miracles, it feels.
Or?
Michiel
Access 2007
hbinc
wrote:
Hi Michiel,
The way I solved this kind of problems a couple of times is by
defining the message string as
"De [strNum] de beste, die [strDing] vindt, krijgt een [strPresent]"),
vbInformation, "Zondagse opgave"
and just before calling the MsgBox substitute the [...]-values by the
current values.
HBInc.
Tony Toews [MVP]
>Someone from abroad might be interested in my application. Ha, new
>perspectives.
>The user interface's language, now, is Dutch.
>I want to translate all that is Dutch into English.
>I made a routine that is able to collect all MsgBoxes in my code and distill
>the Prompt part, Title part, whatever.
>So I could store them in a table. And put the translation in the field next
>to it.
HBinc has given you a good answer for your exact question.
Other resources include
Microsoft Access Multilingual/Localization Solutions
http://www.granite.ab.ca/access/multilingual.htm
A discusson on this topic I started a while back.
http://groups.google.ca/group/comp.databases.ms-access/browse_thread/thread/6192d47eb26260d4/8e6cf8538175f20d
Now a key performance tip is to arrange and read the data from the table/query in to
fill your form report controls with one index read. That is if you have 30 controls
and labels on your form don't do 30 different recordset index "seeks' into the
table/query. Intsead arrange your data so that you do one index "seek" and then read
all the thirty records belonging to your 30 controls one after the other. Now these
don't have to be alphabetical sequence or anything like that. After all it's very
fast changing the control and label caption. But it's relatively slow reading the
data from the tables for each form and report open.
Also you might want to ship your product with the translation tables in a separate
MDB/MDE linked from the FE. This way you can easily update any typos without
reshipping your main program. Also, down the road, it becomes easier to add new
languages and ship just the language MDB.
For performance reasons you probably want that located along side the users FE rather
than being on the server share.
Tony
--
Tony Toews, Microsoft Access MVP
Tony's Main MS Access pages - http://www.granite.ab.ca/accsmstr.htm
Tony's Microsoft Access Blog - http://msmvps.com/blogs/access/
For a convenient utility to keep your users FEs and other files
updated see http://www.autofeupdater.com/
Granite Fleet Manager http://www.granitefleet.com/
Michiel Rapati-Kekkonen
To me it felt like SF: freezing a body to warm it back to life at a later
time.
Maybe you could attend to that problem, too?
Thanks,
Michiel
"hbinc" <j.van...@hccnet.nl> wrote in message
news:1218c2e2-9278-4fad...@m3g2000yqf.googlegroups.com...
Michiel Rapati-Kekkonen
I certainly will take your very sound performance tips to heart.
but typos? me?
Michiel
(btw the first two links plus the fourth on your granite-multilingual page
don't seem to work)
"Tony Toews [MVP]" <tto...@telusplanet.net> wrote in message
news:iiu7i55k7pg0r06qq...@4ax.com...
hbinc
wrote:
> Clever you!
> To me it felt like SF: freezing a body to warm it back to life at a later
> time.
> Maybe you could attend to that problem, too?
>
> Thanks,
>
> Michiel
>
>
> - Show quoted text -
Hi Michael,
Can you explain a little more on what you mean with your sentence:
"Maybe you could attend to that problem, too? "
HBInc.
Tony Toews [MVP]
>I certainly will take your very sound performance tips to heart.
>but typos? me?
Your tongue better be so far in your cheek it hurts. <smile>
>(btw the first two links plus the fourth on your granite-multilingual page
>don't seem to work)
Hmm, I thought I checked.
Tony Toews [MVP]
>Now a key performance tip is to arrange and read the data from the table/query in to
>fill your form report controls with one index read. That is if you have 30 controls
>and labels on your form don't do 30 different recordset index "seeks' into the
>table/query. Intsead arrange your data so that you do one index "seek" and then read
>all the thirty records belonging to your 30 controls one after the other. Now these
>don't have to be alphabetical sequence or anything like that. After all it's very
>fast changing the control and label caption. But it's relatively slow reading the
>data from the tables for each form and report open.
Just to follow up on this one. You might want to go so far as to have a normalized
table with all the unique label text once. For example "Customer". Have the
translation table for that label.
Now you programmatically read all the forms and reports willing in tables with all
the occurances of the various strings. So you probably have at least three tables.
Form/Report name, caption table and junction table with foreign keys pointing to the
two just mentioned table.
(There's also a message table too but we'll ignore that for now.)
To get the maximum performance when opening a complex form with lots of controls you
might want to create a totally denormalized, indexed table from the above three
tables. And do form/report lookups on that single table.
Maybe. Try it on a slow system and see what you think.
Roger
> Tony's Microsoft Access Blog -http://msmvps.com/blogs/access/
Roger
> Tony's Microsoft Access Blog -http://msmvps.com/blogs/access/
> For a convenient utility to keep your users FEs and other files
or you could set up the tables as outlined by Tony
and do the processing once, per language, creating one FE per language
so that users don't have to pay a performance penalty while you
translate the application
Michiel Rapati-Kekkonen
"Roger" <lespe...@natpro.com> wrote in message
news:d38b6057-6710-497b...@33g2000vbe.googlegroups.com...
And that is how I have now done it, indeed.
It now takes two minutes to personalize the application:
messages, labels all translated and the specific options in place.
Thanks all for your very sound advice!
Michiel
--- news://freenews.netfront.net/ - complaints: ne...@netfront.net ---