Meerdere talen

[Theo Tromp]

Hallo allemaal,

 

Voor een klant heb ik een applicatie gemaakt met een Engelse gebruikersinterface. De klant heeft namelijk kantoren in NL, D, UK en US. Alle kantoren werken met dezelfde applicatie (met veel localisatiemogelijkheden).

 

Een belangrijke stap zou kunnen zijn om de gebruikersinterface te vertalen naar het Nederlands en het Duits. Uiteraard wil ik hierbij uitgaan van één ontwikkelversie. Volgens mij zijn er twee alternatieven:

 

1) alle prompts (vaste teksten van de layout) vervangen door rekenvelden en de teksten opnemen in een bestand

2) alle layouts dupliceren en de prompts vertalen. NB ik gebruik al 'intelligente' navigatiescripts dus ik hoef geen scripts aan te passen.

 

Nadeel van 1) is dat schermen trager worden en dat in de zoekmode de prompts wegvallen. Nadeel van 2) is dat je meer layouts moet onderhouden (en de kans loopt dat je layouts vergeet bij te werken). Eigenlijk denk ik dat ik geen vertaalde versies moet maken van de Filemaker applicaties. Of zijn er nog (betere) alternatieven?

[DJ_Lucv]

Filemaker zelf lijkt mij hier niet echt voor bedoeld. Ik zou het dus ook gewoon op Engels houden. Wat je zeker niet moet doen is met meerdere layouts gaan werken, dat is ook niet handig. Een echt handige manier is er, behalve heel veel velden, niet. Ook met een relatie werken gaat niet echt goed, dan heb je weer teveel relaties nodig of een hoop scripting. Nee, ik zou gewoon english only werken.

[Stef]

Die Duitsers een taalcursus cadeau doen!

 

Nee, het is een zwaar geval. Zelf gebruik ik ook een "language file" met één taal per record, per gebruiker kan een taal gekozen worden, met het gevolg dat in één netwerk verschillende gebruikers verschillende talen kunnen gebruiken. Ik gebruik wel slechts één layout voor alle talen, dit met merge fields. Voor zoekschermen heb ik per taal één zoekscherm (dat zijn dan de enige die ik up-tot-date moet houden).

Show message is gelukkig sinds versie 6 geen probleem meer, dat was vroeger nog een extra klus.

Het zwaarste van alles vind ik de value lists.

 

MVG

Stef

[Theo Tromp]

Het zwaarste van alles vind ik de value lists.

 

De gegevens van alle valuelists van de applicatie (inmiddels 42 stuks) staan in één bestand (Table). In Table zijn er drie velden: TabelNaam, TabelWaarde en TabelBeschrijving waarmee respectievelijk de valuelist wordt geidentificeerd, de valuewaarde en de omschrijving. Met Filemaker 6 wordt met de optie "only related values" en met een unindexed calculated field die de Tabelnaam bevat de valuelist gedefinieerd. Voor iedere taal dien ik alleen de gegevens in Table te vertalen.

[Theo Tromp]

Voor zoekschermen heb ik per taal één zoekscherm (dat zijn dan de enige die ik up-tot-date moet houden).

 

Inmiddels heb ik bedacht (en getest) dat je in plaats van calculated fields ook globale velden kunt gebruiken voor de prompts. De inhoud van een globaal veld blijft ook in de Find Mode zichtbaar. De globale velden kunnen na het aanloggen van de gebruiker gevuld worden met de prompts van diens voorkeurtaal. Er zijn dan geen problemen meer met de find mode.

[Theo Tromp]

Nee, ik zou gewoon english only werken.

 

Voorlopig wil ik dat ook doen. Ik zal zien of mijn applicatie een plek krijgt in de markt. Mocht er behoefte zijn aan vertaalde versies dan wil ik me voorbereiden: hetzij doorgaan met Filemaker of overstappen op een zwaardere ontwikkelomgeving waarin vertaalde versies gemakkelijker zijn te realiseren. Samenvattend:

 

- Value lists vertalen is geen probleem, staan al in een tabel

- Voor iedere prompt/taal combinatie een record opnemen in een taalbestand

- Alle prompts in alle layouts vervangen door globale velden

- Al deze globale velden vullen na inloggen vanuit het taalbestand

- Voor alle messages teksten opnemen in het taalbestand (voor de message en voor de knoppen)

[rmw]

- Value lists vertalen is geen probleem, staan al in een tabel

 

En wat nou als op basis van een value list een veld met radiobuttons wordt getoond en op basis van de gekozen radio button een calculatie wordt uitgevoerd?

Dan is vertalen dus de oorzaak van het niet meer werken van de calculatie.

[Theo Tromp]

En wat nou als op basis van een value list een veld met radiobuttons wordt getoond en op basis van de gekozen radio button een calculatie wordt uitgevoerd?

Dan is vertalen dus de oorzaak van het niet meer werken van de calculatie.

 

Je hebt helemaal gelijk. Je zou in een dergelijke situatie ook in de tabel met value-lists voor iedere optie een nummer kunnen opnemen. Middels een opzoekrelatie kan dan van de gekozen tekst het nummer worden opgezocht en dat kan worden gebruikt in de berekening. Ik geef toe, wel een beetje omslachtig.

[Sanne]

- Value lists vertalen is geen probleem, staan al in een tabel

- Voor iedere prompt/taal combinatie een record opnemen in een taalbestand

- Alle prompts in alle layouts vervangen door globale velden

- Al deze globale velden vullen na inloggen vanuit het taalbestand

- Voor alle messages teksten opnemen in het taalbestand (voor de message en voor de knoppen)

 

Jep, ben ik een eind mee eens.

 

Wat wel nog ter overweging meegenomen kan worden, denkend aan de English-only optie:

 

Ik werk nu ook met een meertalig FileMaker-systeem (grofweg via bovenstaande methode). Hoewel het voor de "prompts" (ik neem aan dat daar o.a. de veldnamen mee bedoeld wordt) uitermate goed werkt (veel breinloos programmeren, dat wel), is de informatie die in de velden door de gebruikers wordt ingevoerd vaak maar in één taal beschikbaar.

 

Ik bedoel: de gebruikers hebben een fantastisch Nederlands en Engelse toepassing om mee te werken, maar de informatie die in de toepassing in de velden staat is overal Nederlands!

Dit lijkt mij voor de gebruikers die de Nederlandse taal niet machtig zijn niet altijd even handig (mij ontbreekt overigens even de feedback op dit punt).

 

Een toepassing die in een meertalige werkomgeving draait, zal snel uitkomen op de afspraak binnen de organisatie: we praten allemaal (vul hier de naam van een taal in). En dan kom je dus weer terug op een één-talige toepassing: in het Babelonisch.

[DJ_Lucv]

Het is natuurlijk totaal afhankelijk van je applicatie. Bijvoorbeeld voor een CMS is meertaligheid noodzakelijk omdat de content vaak ook in meerdere talen beschikbaar moet zijn.

[Theo Tromp]

Ik bedoel: de gebruikers hebben een fantastisch Nederlands en Engelse toepassing om mee te werken, maar de informatie die in de toepassing in de velden staat is overal Nederlands!

 

Sanne voor mij speelt dit niet. De toepassing draait in vier landen met in ieder land een eigen database (en dus is de inhoud gevuld met gegevens van één land c.q. taal). Het doel voor mij is dat ik slects één ontwikkelomgeving wil die ik vervolgens min of meer onaangepast kan distribueren. Overigens veel succes met jouw applicatie!