FE / BE database in a multilingual context

Question

Hi

Is there a "smooth" way to handle the FE in a multilingual company?

I mean is there a dynamic way to change text on Forms and Reports depending on the language of the user.

---

Best // Peter Forss Stockholm and Sigtuna GMT +1.00

Answer 1

There is a really cool example of this from MontaRibbons at http://www.ribbons-access.com/

I can't remember which of their videos showed it, but they do this to their ribbon and some forms. I think they hold the translations in a table, and let user decide which language after login. Then they refresh the ribbon and forms load their control captions/labels from different field in table depending on language.

Of course, this is just an small example. You will have to expand on the idea yourself.

Answer 2

Hi Peter,

No promises but take a look at this old thread at UtterAccess.

Hope that helps...

Answer 3

Is there a "smooth" way to handle the FE in a multilingual company?

I mean is there a dynamic way to change text on Forms and Reports depending on the language of the user.

Hi Peter,

It all depends om your way of working within Access. For standard Access I do not know the answer.

In my systematics I use generalized forms. All abstract definitions of the forms are translated to readable information through meta data tables. Because of the use of this first "translation" possibility, it is no point to add further translation possibilities to other languages.

Someway you need a translation systematics. Thinking further, and when you have that, you are ready for generalization.

Imb.

Answer 4

Auto-translation has its pitfalls.  If you are not careful you could end up with Hoffnung's 'There is a French widow in every room'  or as with an estate agency in Greece which I helped out a while ago (and I'm not making this up), 'There are olive trees growing in the owner's rear end'.

In my organisation each user's front end was in their personal location on the system, to which only they had access, so it was simply a matter of tailoring the copy of the front end to the person concerned.

---

Ken Sheridan, Stafford, England

Answer 5

I believe the only practical approach is to make separate form/report objects.  I doubt the effort to change language within a single object is worth the effort for most situations particularly in regard to labels and such.... To me the only type form/report that would make sense to toggle language would need to be a very grid-like object such that all the terminology is able to come from columns of a table whereby one could rely on the query record set to select the language.

If one has wholly duplicated form/report objects by language - then the decision is to either have separate FEs, or a single FE where either the user selects their language - or potentially based on a log-in profile which indicates language - and then have the database do the selection of which version object gets opened.

My 2 cents.

Answer 6

Thank you all for good ideas!

---

Best // Peter Forss Stockholm and Sigtuna GMT +1.00