Meertaligheid in APEX applicaties

December 2009 - Het wereldwijde web is, zoals de naam al zegt, wereldwijd te benaderen. Hierdoor zijn openbare webapplicaties per definitie te bereiken voor mensen met allerlei achtergronden. Om deze simpele reden is het regelmatig nodig om applicaties te ontwikkelen die de land- en dus taalgrenzen overschrijden. In sommige gevallen wordt er simpelweg gekozen om een webapplicatie te ontwikkelen die in het Engels is geschreven, maar om een hogere gebruikersvriendelijkheid en gebruikersgemak te verzekeren is het vaak nuttiger om een gebruiker te bedienen in zijn of haar eigen taal.

Oracle Application Express biedt standaard een aantal simpel toe te passen mogelijkheden en hulpmiddelen om een applicatie meertalig te maken, zonder extra programmeerwerk. In dit Whitebook laten we een aantal van deze mogelijkheden zien en leggen we uit hoe deze toe te passen.

Niveau’s van meertaligheid

Om een APEX applicatie meertalig te ontwikkelen onderscheiden we vier verschillende niveaus. Met behulp van deze niveaus is het mogelijk om een generieke applicatie te ontwikkelen die meertalig benaderd kan worden. Deze vier niveaus zijn:

• Applicatielabels. Met behulp van Applicatielabels worden de verschillende elementen binnen de applicatie zelf bedoeld. Hiermee worden, onder andere, de paginatitels, headers van reports en forms en bijvoorbeeld de getoonde tekst op buttons bedoeld.
• Meldingen. Fout (en succes) meldingen worden binnen APEX weer als volgend niveau behandeld. Deze gegevens worden getoond op het scherm nadat een actie niet is toegestaan of juist om aan te geven dat een actie in de webapplicatie succesvol is geweest.
• Data. Uiteraard mag de data zelf ook niet buiten de boot vallen. Zo kunnen bijvoorbeeld namen van producten of omschrijvingen verschillen per taal. Deze zullen echter binnen de database bijgehouden moeten worden en dienen met een query opgehaald te worden.
• Referentiecodes. Op het moment dat een applicatie werkt met meertaligheid is het praktisch om te werken met referentiecodes. Dit om ervoor te zorgen dat, mochten algemene gegevens meerdere malen in een applicatie voorkomen, deze slechts op één plaats bijgehouden moeten worden.

Globalisatie van de Applicatie

Het definiëren van een meertalige applicatie in APEX begint met het kiezen van de standaard (default) taal van de applicatie en de manier waarop de overige talen moeten worden getoond. Deze definitie vindt plaats bij het creëren van de applicatie op het tabblad Globalization binnen de Application Definition, welke te vinden is onder het menu Shared Components.

Figure 1 Globalisatie attributen

Onder de optie ‘Application Language Derived From’ zijn een aantal mogelijkheden te zien. Deze mogelijkheden geven aan hoe de applicatie moet bepalen welke taal getoond moet worden. Opties zijn bijvoorbeeld om te kiezen voor de standaard taal van de browser, voor een applicatie parameter of voor een item parameter. In het voorbeeld dat hier verder wordt uitgewerkt, kiezen we voor de laatste optie, de door een item in de applicatie meegegeven taalparameter.

Het gebruik maken van een Item Preference voor de keuze in taal geeft ons de flexibiliteit om op elk gewenst moment de taal van de applicatie te wijzigen. Het enige dat daarvoor dient te gebeuren, is het aanmaken van een Application Item met de naam FSP_LANGUAGE_PREFERENCE en deze vervolgens in de applicatie gebruiken. Een valkuil daarbij is wel, dat het aanroepen van een pagina na het wisselen van de taal niet meteen voor een zichtbaar resultaat zorgt. Dit komt door de opbouw van een pagina in APEX. Eerst worden de te tonen gegevens bepaald en daarna wordt pas gekeken welke taal moet worden gebruikt. Om dit op te lossen kan een Application Process worden gemaakt, welke op het ‘OnLoad event’ zorgt dat de pagina nog een keer wordt opgebouwd. Dit gebeurt met behulp van de volgende code:

owa_util.redirect_url('f?p='||:APP_ID||':'||:APP_PAGE_ID||':'||:APP_SESSION);

Selecteren van de taal

Om er zeker van te zijn dat het applicatiebrede proces om de voorkeurstaal in te stellen maar een keer wordt aangeroepen, wordt aangegeven dat deze alleen mag worden aangeroepen op het moment dat er daadwerkelijk van taal gewisseld moet worden. Hiervoor wordt de ‘Condition’ van het proces gesteld op het Request ‘LANG’. Op de plekken waar on-the-fly van taal gewisseld moet worden, kan dit Request worden geactiveerd en meegegeven.

In de applicatie die wij hier ter demonstratie gebruiken is dit gedaan door in de Navigation Bar in de Shared Components een tweetal Entries op te nemen die verwijzen naar de juiste taal, zie ook onderstaande schermafbeelding voor het resultaat.

Figure 2 Vertaalbaar scherm

Deze Entries worden gedefinieerd op onderstaande manier:

Figure 3 Navigation Bar Entry

Zoals te zien is, worden het Request en het Application Item gezet en wordt daarnaast de huidige pagina opnieuw aangeroepen door gebruik te maken van de ingebouwde variabele &APP_PAGE_ID.

Standaard Vertaalbestand, XLIFF

In principe is het bovenstaande voldoende om de applicatie klaar te maken voor meertaligheid. Het enige dat nu nog moet gebeuren is de vertaling zelf. Application Express maakt hiervoor gebruik van de XLIFF standaard (XML Localization Interchange File Format). Dit zijn speciale XML bestanden waarin opgenomen is wat de oorspronkelijk taal is en in welke taal moet worden vertaald en daarnaast een lijst met zogenaamde Source en Target elementen.

In de Source elementen zij de diverse labels opgenomen die APEX kan vertalen, zoals deze zijn gebouwd in de originele applicatie. In de Target staan diezelfde labels, maar deze kunnen door de gebruiker worden vervangen door de gewenste tekst in de taal waarin vertaald moet worden.

De structuur van een dergelijk bestand ziet er als volgt uit:

<xliff version="1.0">
  <file original="f125_126_en-us_nl.xlf" source-language="en-us" target-language="nl" datatype="html">
    <header></header>
    <body>
      <trans-unit id="S-2-3375621609702167-125">
        <source>Logout</source>
        <target>Uitloggen</target>
      </trans-unit>
      <trans-unit id="S-14-3376110917702171-125">
        <source>Password</source>
        <target>Wachtwoord</target>
      </trans-unit>
      <trans-unit id="S-14-3376206121702171-125">
        <source>Login</source>
        <target>Inloggen</target>
      </trans-unit>
    </body>
  </file>
</xliff>

In het element trans-unit staat een uniek identificerende code voor het label. Deze code gebruikt APEX om het label aan het juiste item te verbinden.

Stapsgewijs vertalen

Het proces om een XLIFF bestand te genereren en te importeren verloopt volgens een aantal vaste stappen. Application Express biedt een overzicht van deze stappen in een lijst die te vinden is onder Shared Components, Translate Application.

Figure 4: How to translate: stapgewijs vertalen in APEX

Stap 1 is het aanmaken van een Mapping van de originele taal naar de gewenste nieuwe taal. Hiervoor moet een nieuw applicatie nummer worden ingevoerd. Dit nummer gebruikt APEX om een soort semi-applicatie te maken die niet te zien is in de Application Builder en ook niet los is aan te roepen. In feite is het een replica van de hoofd applicatie waarin de labels worden gevuld door het XLIFF bestand.

Op basis van deze mapping kan vervolgens een proces worden gestart waarin alle vertaalbare objecten in de applicatie worden bepaald. Dit proces heet ‘Seeden’ en is Stap 2 van het vertalen in APEX. Dit ‘Seeden’ is vervolgens de basis voor het genereren van het XLIFF bestand.

Figure 5 Seeden van vertaalbare teksten

Figure 6 Exporteren van een XLIFF bestand

Zoals te zien is in de figuur, kan een XLIFF worden geëxporteerd op basis van de gehele applicatie of op basis van een specifieke pagina, dit is stap 3 in het vertaalproces. Daarnaast kan worden gekozen om alle elementen te exporteren, of te beperken tot die elementen die nog niet zijn vertaald (in de praktijk betekend dit alle objecten waarbij de Source en de Target gelijk zijn).

Na het handmatig aanpassen van het XLIFF bestand kan deze terug worden ingelezen in de applicatie. Stap 4 uit het globalisatie stappenplan opent hiervoor een scherm waarin het bestand kan worden geupload. Het bestand moet vervolgens aan de juiste mapping worden verbonden.

Figure 7 XLIFF bestand geupload

Figure 8 XLIFF bestand toepassen op de juiste mapping

Als laatste moet de vertaalde applicatie worden gepubliceerd, hiermee zijn we bij de laatste stap beland.

Figure 9 Publiceren van de vertaalde applicatie

Hiermee is de applicatie vertaald. Het is mogelijk om naast deze acties, waarmee slechts de Applicatielabels en Meldingen zijn vertaald, ook de applicatie vanuit het datamodel zo op te bouwen dat de getoonde gegevens, data en referentiecodes, meertalig te benaderen zijn.

Door het datamodel in te richten voor meertaligheid en gebruik te maken van referentiecodes voor enkele algemene vertalingen in data, vertalingen die vaker voorkomen, is het mogelijk om de complete applicatie in een bepaalde taal te zetten. Hier kan men denken aan, bijvoorbeeld, meertalig opgezette lists of values (LOV’s) en taalspecifieke queries voor reports. Hiermee kan simpelweg de parameter FSP_LANGUAGE_PREFERENCE meegegeven worden in de where clausule.

Conclusie

Met behulp van Oracle Application Express is het mogelijk om, in korte tijd, een veilige en snelle webapplicatie te ontwikkelen. Ook biedt deze tool de juiste middelen om de ontwikkelde webapplicaties in meerdere talen te ontwikkelen met bijzonder weinig inspanning. Door deze eigenschappen kan een organisatie zijn dienstverlening in korte tijd via het web ontsluiten en dit niet langer alleen binnen de taalgrenzen. Het internet gaat grenzen over, webapplicaties nu ook.

Referenties

• Pro Oracle Application Express van John Scott en Scott Spendolini (ISBN 978-1590598276)
• Broncode Demo-applicatie (APEX application export plus het XLIFF-bestand)