Multi-Language in een applicatie

[SuperWimmie]

Dag allemaal,

 

Ik ben voornemens om een Filemaker applicatie op de markt te gaan brengen welke internationaal ook best eens interessant kan zijn.

Tot nu toe maak ik altijd alles in het Nederlands.

 

En nu komt hij: wie heeft ervaring met het multi-language maken van scripts en layouts?

 

Er zijn diverse vormen te bedenken die je kan toepassen, maar het lijkt me een berg werk. Om het gelijk in een goed richting te duwen, zijn tips van harte welkom!

[JeanWM]

Doorgaans zijn mijn applicaties Engels/Spaans, maar enkel op layout gebied.

 

Tooltips, messages, knoppen, etc zijn ook keuze/meertalig.

 

Ik begrijp niet goed je meertaligheid voor scripts, die blijven op de achtergrond, daar heeft de gebruiker niets te zoeken.....

 

Afhankelijk van de grootte van de applicatie gebruik ik al of niet repeating fields voor de language engine.

[SuperWimmie]

Custom Dialog is ook zo'n ding. Vandaar scripts meertalig.

 

Maar ik begrijp hieruit dat je de layouts dupliceert en vertaalt?

 

Ik ken ook nog iemand die een complete vertaaltabel heeft opgezet, alle tekstjes zijn dan globale velden die via een berekening zijn info uitleest uit de vertaaltabel.

Het lijkt mij wel mooi als je nog meer talen hebt, maar ook erg omslachtig.

 

Engels en Nederlands lijkt mij voorlopig voldoende.

[JeanWM]

Custom Dialog is ook zo'n ding. Vandaar scripts meertalig.

 

Die zitten vervat in mijn 'messages'. Het zijn enkel de 'teksten' die je conditioneel dient te maken....

 

Maar ik begrijp hieruit dat je de layouts dupliceert en vertaalt?

Neen, geen enkele dupe layout. Er is een vertaal module waar we zoveel 'talen' in kunnen stoppen als we willen/nodig hebben.

Die module is relationeel verbonden met alle tables.

 

De veldlabels worden als merge fields op de layouts gezet, of als berekeningsveld.

 

Ik ken ook nog iemand die een complete vertaaltabel heeft opgezet, alle tekstjes zijn dan globale velden die via een berekening zijn info uitleest uit de vertaaltabel.

Het lijkt mij wel mooi als je nog meer talen hebt, maar ook erg omslachtig.

 

Of je gaat relationeel of je doet het met calculaties of je doet het met repeaters die je op tijd en stond ophaalt.

Omslachtig is het niet, omdat je telkens zaken kunt bijvoegen.

 

Als je merged maakt het geen erschil uit of je een gewoon label op je layout zet of een merge field.

Een merge filed heeft dan nog het voordeel dat je bijzonder klein in font size kunt gaan....

[SuperWimmie]

Find modus geeft geen problemen?

[JeanWM]

Waaraan denk je dat Find mode een probleem zou kunnen zijn?

[SuperWimmie]

mjha... bij gewone velden is dat wel degelijk het geval omdat alle velden leeg gegooid worden. Tevens moet de sleutel actief zijn ten tijde van de zoekmodus. Als die ook leeg staat om daar zoekargumenten in te gooien, dan tref je een onbenoemd scherm.

 

Maar het kan opgelost worden, lijkt me.

[JeanWM]

Nu kan ik even niet meer volgen....

[BURODOK]

ècht internationaal is niet mogelijk met filemaker, om de volgende redenen.

 

1. de formattering van datums (mm-dd-yyyy) en getallen (000,000.00) kan alleen hard gecodeerd worden in filemaker. als je dus bijvoorbeeld éénmaal een komma als decimaalteken hebt opgegeven voor een getalveld dan kan je die niet op basis van een berekening veranderen in een punt als dat nodig is.

2. invoerlijsten idem.

3. en dan de knoppen van je dialoogvensters: hard gecodeerd.

 

conclusie: zelfs als je heel veel werk steekt in een oplossing met een beperkt en vast aantal talen (voor iedere taal aparte dialoogvensters definiëren in je scripts en extra tabellen en relaties voor je invoerlijsten) dan nog maken datum- en getalformattering de hele inspanning voor niets. hoog tijd dat filemaker na 25 jaar eens volwassen wordt...

[JeanWM]

Getallen en datum vang je heel gemakkelijk op met calculated validation.

 

Knoppen van dialoogvensters zijn niet hard coded omdat we nooit de native dialoogvensters van FM gebruikt hebben of gebruiken.

 

We hebben verschillende applicaties lopen in Spaans/Portugees/USEngels.

Daarin hebben we geen problemen met verschillen in cijfer/datum/tijd aanduiding.

 

Valuelists worden apart opgemaakt. Geeft zo al meer flexibiliteit.

[andries]

Wij hebben twee tabellen om de vertalingen te gaan beheren.

 

Een tabel Labels, en dan een tabel met de vertalingen per label per taal. Bij het opstarten bepalen we de taal, en laden in een globaal veld (repeated) de juiste vertalingen van de labels. Deze repetities gebruiken we dan als labels op de layouts of als tekst in de dialoogvensters.

 

Het enige probleem zijn inderdaad de knoppen van de dialoog vensters, maar we proberen dit meestal op te lossen door de tekst zo op te stellen dat het met OK of cancel kan opgelost worden. Indien dit echt niet kan, ben je wel verplicht om in je script met if statements verschillende dialoogvensters te gaan bepalen.

 

Maar verder is dit systeem waterdicht, maar duurt het wel even bij het opstarten om ze in de globaal in te laden.

 

Custom Valuelists worden dynamisch opgebouwd (en zijn dus niet meer custom:-) ), en verwijzen naar een vertaling in de vertalingen tabel. Op die manier kan je ook makkelijk conditionele "custom" valuelists maken en zo en dit is weer een mooie extra feature dat hier mee meekomt.

[Mark]

De oplossing die Andries beschrijft is bijna het zelfde zoals ik het heb gedaan.

Een tabel met labels en vertalingen o.b.v. TaalID en TextID en een tabel (een record) met een global repeating veld. Dit werkt goed en ik moet zeggen dat 221 records supersnel in de global worden gezet.

 

Het probleem met de dialoog vensters heb opgelost met Dialog Plug-In van Troi.

 

Ik heb een applicatie draaien in het Nederlands, Engels en Noors en er zijn geen probleem met datum en getal notaties.

Je dient Data Entry (in File Options) wel op "Always use current system setting" te zetten.

Edited June 18, 2010 by Guest

[SuperWimmie]

Ah, jullie laden de taalafhankelijke teksten in globale velden?

 

Dus geen rechtstreekse verwijzing naar de vertaaltabel? Want dat zou ook nog mogelijk kunnen zijn, dan ben je van al die globalen helemaal af.

 

Vandaar dat ik zat te kijken met de find modus, globale velden behouden tijdens de find modus hun waarden.

Als je rechtstreeks de vertaaltabel uitleest (zonder globale velden), moet de sleutel ook zijn waarde hebben om de gerelateerde velden te kunnen tonen tijdens de find modus.

 

Ik ga eens puzzelen.

[Mark]

Nee, het is een enkele repeating global die je van te voren instelt (startscript) o.b.v. de gewenste taal. Stel dat je een tabel Local hebt met daarin een repeating global genaamd Teksten. Op de repetition 7 staat bijvoorbeeld het woord Nieuw. Sleep een veld naar de gewenste layout, selecteer het veld Local::Teksten, zet Show repetitions op 7 through 7 en voila!

 

Een directe link vanuit elke tabel is zo omslachtig (onnodige relaties) en je hebt geen probleem met de Find Mode.

[Joris Aarts]

Mijn kleine steentje bijdragen aan de discussie: merge variables (nieuw in FM11) openen misschien perspectieven om het trage laden van velden (relationeel of globaal) te omzeilen... Ik heb het nog niet in de praktijk toegepast voor vertalingen, maar ik kan me inbeelden dat er minder overhead kruipt in het instellen van variabelen. Volgens mijn ervaring gaat het instellen van globale velden traag.

 

Als je variabelen aanstuurt in plaats van velden win je aan flexibiliteit en verminder je ballast: geen TO's meer in je graph om die labels te voeden, geen relaties meer. Zo zou je ook systemen kunnen verzinnen waarbij die vertalingsvariabelen progressief worden gevuld al naargelang de layouts die je activeert. Met een naming convention en de functie GetLayoutObjectNames kan je snel alle nodige labels oppikken en on-the-fly opvullen met de juiste vertalingen.

 

Maar eerlijk, ik heb het nog niet in de praktijk toegepast. Het zijn maar ideeën. Of de hitte die me parten speelt

[SuperWimmie]

Gaan we toch eens uitproberen, Joris. Het vergt wel een ijzeren discipline om alle naamgevingen exact gelijk te houden.

 

 

Ander vraag: Value lists, hoe daar mee om te gaan?

 

Ik heb bijvoorbeeld de keuze uit "links rechts onder boven" en dat wordt hard in de code en taal opgenomen...

Terwijl ik de layout hetzelfde wil houden, de code idem.

 

Stel dat je de value lists apart maakt, dan mag je bij een taalswitch alle sleutelvelden die op de vaste valuelists zijn gebouwd opnieuw doorvoeren... ook niet ideaal.

[hbrendel]

Ja, het wordt hoog tijd, dat er in de valuelists een optie 'van calculatie' wordt toegevoegd...

[andries]

inderdaad...

 

een oplossing is weer twee tabellen: 1 voor de valuelists en valuelistitems ( dus een foreign key naar de parent record ), en een tabel met vertalingen, en dan heb je vertaalde waardelijsten, maar dat is ook niet altijd ideaal... duurt soms lang om in te laden etc...

[Joris Aarts]

Hey,

 

voor die meertalige value lists, zou ik het principe van "virtual lists" toepassen. Techniek is van Bruce Robertson, beschreven in Advisor magazine en uitgelegd op de laatste FM Summit door Koen Van Hulle.

 

Groetjes,

 

Joris

[SuperWimmie]

Oeps... Ik zie de oplossing ergens wel, maar dit betekend een kleine conversie in de huidige omgevingen.

 

't Is niet anders, lijkt me.

 

1 onder

2 boven

3 links

4 rechts

 

is dan te vertalen. Als de taalcode ergens in de lijn der sleutels meespeelt, hebben we de juiste taal te pakken.

 

Helaas weer niet in de zoekmodus. Maakt in dit geval gelukkig niet zoveel uit.

 

@ Joris: is dat artikel ook ergens op het grote Web te verkrijgen?

[JeanWM]

merge variables (nieuw in FM11) openen misschien perspectieven om het trage laden van velden (relationeel of globaal) te omzeilen... Ik heb het nog niet in de praktijk toegepast voor vertalingen, maar ik kan me inbeelden dat er minder overhead kruipt in het instellen van variabelen. Volgens mijn ervaring gaat het instellen van globale velden traag.

 

Klopt, indien het een 'grote' toepassing is.

 

Als je variabelen aanstuurt in plaats van velden win je aan flexibiliteit en verminder je ballast: geen TO's meer in je graph om die labels te voeden, geen relaties meer.

Onze (ver)taal engine heeft twee TO's in een geisoleerde TOG. Ik zou dat geen ballast willen noemen in vergelijking met alle andere relaties die aanwezig (zouden) zijn.

 

Zo zou je ook systemen kunnen verzinnen waarbij die vertalingsvariabelen progressief worden gevuld al naargelang de layouts die je activeert. Met een naming convention en de functie GetLayoutObjectNames kan je snel alle nodige labels oppikken en on-the-fly opvullen met de juiste vertalingen.

 

Ik zie hier 1 punt dat langzaam zal verdwijnen. Indien je een 'nieuwe' feature gebruikt, sluit je de weg af om de toepassing 'met een vorige versie' te gebruiken. Niet iedereen heeft onmiddellijk en altijd de laatste versie.

Toegegeven, een nadeel dat mettertijd gaat verdwijnen....

 

Je moet inderdaad steunen op een zeer strikte naming convention om de 'concomitant burden' vind niet onmiddellijk het nederlandse woord van het bijhouden van iedere variable te vermijden.

 

Het grootste nadeel (volgens mij) is, vermits variables niet 'gestored' worden (o.a. de reden waarom ze zo efficient kunnen gebruikt worden), gebruiken ze geheugen gedurende de tijd van de 'instantiation' (geen nederlands woord voor dit).

 

Op zich is dit zeker geen show stopper, maar niet iedereen heeft een bakbeest van een computer met multi GB aan geheugen.

 

Mijn 2 centavos bijdrage aan het steentje terwijl Alex als storm lelijk aan het huishouden is.

[Joris Aarts]

Onze (ver)taal engine heeft twee TO's in een geisoleerde TOG.

Gaat het echt om een geïsoleerde TOG? Eerder zei je dat er relaties nodig waren naar alle tables. Dat is voor mij een show-stopper: ik ben momenteel nog steeds groot voorstander van anker-boei en hou m'n graph graag clean.

 

Met er nog wat over na te denken, zie ik het steeds duidelijker (FM11 only!):

• gebruik als veldlabels in elke layout merge variables met strikte naming convention (die hou je er sowieso toch best op na, in gelijk welke programmeertaal overigens).
  
• zorg dat je merge var. genoemd is naar de veldnaam waar ie bijhoort.
  
• voorbeeld: <<$$lblVoornaam>> waarbij lbl de prefix is die je scripts vertelt dat het om een te vertalen label gaat.
  
• maak een script dat alle layouts overloopt, er via design functie FieldNames ( fileName ; layoutName ) er alle te vertalen veldnamen afschraapt en die verzamelt in één tabel.
  
• Voilà: je complete vertaaltabel gratis en voor niets en je hoofdtaal staat al klaar (alle lbl-objecten, zonder de lbl), op voorwaarde dat je de veldnamen leesbaar hebt gehouden.
  
• Maak het eigenlijke vertaalscript, dat via de Evaluate functie je variabelen dynamisch genereert volgens de actieve layout en daarbij ineens de juiste vertaling in de variabele stopt. Je zou dat aan een script trigger kunnen koppelen, zodat het automatisch gebeurt bij het (voor de eerste keer) inladen van een layout.

 

Voordelen?

• Geen velden te definiëren.
  
• Ingeval van oplossing met repeating globals: onthouden in welke repetition wat ook al weer stond
  
• Je blijft gewoon in layout modus werken
  
• Geen vertaaltabel die manueel moet worden uitgebreid als er nieuwe veldlabels bijkomen (de vertalingen moet je natuurlijk wel nog voorzien).
  
• Eén TO voor de vertaaltabel. Géén relaties.

 

Nadeel: FM11 only. Dju toch

 

@SuperWimmie: artikel van Bruce voor zover ik kon vinden alleen via FileMaker Advisor. In één zin samengevat: het is een techniek om van eender welke return-gescheiden lijst ( scriptmatig opgebouwd, copy/paste uit bv. FInder, etc...) een reeks records aan te maken. Die records kan je dan gebruiken voor value lists, subsummaries edm. Voordeel: je kan records gebruiken waar FM er nodig heeft (value lists, subsummaries, ...) maar waar er eigenlijk geen zijn.

 

Cheers,

Joris

[JeanWM]

We hebben verschillende systemen lopen.

 

De oudste gaat terug naar FM 3, de eerste keer related.

 

In het begin van de multi-table versie gingen we over naar een systeen met een dictionary table.

 

Nu hebben we twee relaties in 1 geisoleerde TOG.

 

We zijn misschien oud, maar soms gaan we 'mee met de tijd'.

[WJ]

Kijk ook eens naar

http://www.nightwing.com.au/FileMaker/demos9/demo911.html

 

Maar de nieuwe optie global merge variable van joris klikt goed, hoewel nieuwe facetten van filemaker altijd voorzichtig benaderen.

De filter portal optie wordt al heel snel langzaam bijvoorbeeld. Je zou zeggen dat de globale variable weinig pijn kunnen doen maar ik zou het toch even checken.

 

Groet,

 

WJ

[Joris Aarts]

hoewel nieuwe facetten van filemaker altijd voorzichtig benaderen

Je kan niet voorzichtig genoeg zijn

Ik ben ondertussen genoeg bang gemaakt om het eens te proberen. In bijlage een bestandje dat op commando 100, 1000, 10000 en 100000 globale vars aanmaakt en die vult met een relatief lange tekenreeks. Ik vermoed dat zelfs voor uitgebreide apps toch ongeveer 1000 label-variabelen moeten kunnen volstaan. Kijk voor uzelf.

 

Er is natuurlijk een impact op het geheugengebruik van FileMaker. Maar ik heb de indruk dat het inladen van pakweg 1000 global vars niet zo dramatisch veel voorstelt. Het openen van een tweede of derde FileMaker file is véél erger

 

Groetjes,

Joris

Create_Global_Vars.fp7.zip

[andries]

maar wat heb je aan 100 000 variabelen met de zin "The Quick Brown Fox Jumps Over The Lazy Dogs"?