Gustav Brock
Gustav at cactus.dk
Fri Jan 5 08:13:07 CST 2007
Hi John My thoughts are only about the table structure which should be: tblLanguage LCID PhraseKey Translation and a lookup table for the language name: tblTranslation LCID Language Now, lookup your language of choice, say, English US. LCID is 1033 Then lookup the phrase using LCID = 1033 and your key. For "Hi" that might return "Hello". Had you used LCID = 3081 it might be "Howdy". You would need to handle the case where the lookup is unsuccessful. You could define a default LCID which is used if a phrase for another LCID is not found. And you could return the PhraseKey itself if nothing is found. Also, you may choose to format the PhraseKey in a way that separates it from normal text, for example by preceding it with a $ sign. This way, if your button is labeled "$Hi" you would know that the translation is missing. Of course, you may wish to read in all entries for your chosen LCID in a collection or an array - or a static recordset. That depends and is up to the developer. I have no objections regarding this choice. /gustav >>> jwcolby at colbyconsulting.com 05-01-2007 12:33 >>> I don't understand your objection. In a collection the key is just an index into an array (of sorts). The key can be any text string. So if I store "Hola" with a key of "Hello", I can then look up "Hola" simply by using the syntax MyCol("Hello"). Likewise if I store "Hello" and use "Hola" for the key, I can do a reverse translation. Thus you store all of your words and phrases in a table, Language1 in column1, Language2 in column2. Read the table, store column1 keyed on column2. Now take a phrase from the form and use it as the key, look up the value. That simple. Whether you do a lookup in a table or a collection is irrelevant in terms of the concept. Of course this implies that every string value in the form is in the table, but that is true with a seek method as well. Any value in the form not in the table will not return a value whether using a collection or seeking the original table. The only thing the collection does for you is cache the table in memory and increase the speed of access 100 times or so. You could certainly use the control name (with the form name to make it unique) for the key (for example), but then you would probably end up with the same language strings stored multiple times. In the end, if label1 on form1 says "hello" and label 3 on form 20 says "hello", looking up "hello" in the table gets back the translated value, but you only have to store one value of the phrase "hello". Using the formname-controlname as the key means you have to now store two values for the string "hello". In ANY EVENT, you have to have a method of scanning all of the language phrases out of the controls and into a table, then have a method of viewing each phrase and performing a translation. Once you have each phrase and its translation, you are gold. I did all this stuff long ago for a program I wrote for a maquilla in Mexico. At that time I did not use a collection (because I didn't know about them), but the concept is exactly the same regardless of whether you use a table or a collection. All the collection does for you is hold the table contents, item for item, and (dramatically) decreases the time required to do the lookup. John W. Colby Colby Consulting www.ColbyConsulting.com -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Gustav Brock Sent: Friday, January 05, 2007 5:47 AM To: accessd at databaseadvisors.com Subject: Re: [AccessD] Select language (was: A Question of Timing) Hi John et al I would advice against that. Handle the English language as any other language. Then use a key - in plain readable programmer-English understood by you, the programmer - for the entry. This allows you - at any time - to edit the English text as well as the text in any other language without changing the form or report. Also, don't forget that "English" (ignoring old and middle age English) comes in 13 varieties: http://www.science.co.il/Language/Locale-Codes.asp /gustav