Internationalisering of internationalisatie

Geplaatst door Danny Lagrouw zo, 29 jan 2006 03:14:00 GMT

Is het internationalisering of internationalisatie? I18N dan maar, dan weet iedereen wat ik bedoel. Een onderwerp dat helaas lijkt te zijn ‘vergeten’ in Ruby on Rails—terwijl de bedenker nota bene uit Denemarken afkomstig is.

Ongetwijfeld zal het niet lang duren voordat deze leemte kan worden opgevuld met een los ontwikkelde plugin of module. En dat is nu juist jammer; een standaard oplossing, meegedownload met Rails, had kunnen voorkomen dat we in de toekomst in verschillende projecten rekening moeten houden met verschillende oplossingen, of erger nog, zelfgeschreven oplossingen.

Een voorbeeld van zo’n I18N-oplossing voor Rails is Globalize. Globalize is een plugin voor Rails. Je kunt er vertalingen van teksten mee opslaan in de database, en deze vertalingen transparant weer ophalen, bijvoorbeeld:
Locale.set("en-US")
prod = Product.find(1)
prod.name -> "Meatballs" 

Locale.set("nl-NL")
prod = Product.find(1)
prod.name -> "Gehaktballen" 
Een nadeel hiervan lijkt me dat de vertalingen sterk gekoppeld worden aan database records. Als er nog een ander product is met de naam ‘Meatballs’, dan staat niets je in de weg om daar een andere vertaling bij op te slaan. En zelfs als je dezelfde vertaling gebruikt, dan zal die vertaling dus dubbel worden opgeslagen. Deze oplossing lijkt me dan ook het meest geschikt voor het vertalen van database-inhoud. Voor het vertalen van statische tekst zie ik meer in de Java-oplossing, waar vertalingen worden opgeslagen in resource bundles (tekstbestanden). Je vraagt een vertaling op aan de hand van een sleutelwaarde, met een method call of (in een JSP) met een tag. Dat laatste zie ik in een Rails rhtml-bestand dan weer heel mooi voor me:
<%= "label.enter.productname".translate %>
(waarbij voor ‘translate’ nog een passend afgekort alias gebruikt kan worden).

Geplaatst in ,  | 2 reacties

Reacties

  1. procreate zei 104 dagen later:

    Ik snap het niet helemaal, maar dat ligt vaak aan mij. :).

    Ik vind het juist prachtig dat je je db content kan vertalen. En over het dupliceren van meatballs, dat lost ‘validates_uniqueness_of’ op.

    Verder zorgt ’.t’ (of ’.translate’) voor vertalingen van tekst in je views (statische tekst) of waar dan ook (op dezelfde manier als gettext dat doet). De sleutelwaarde is dan de tekst zelf, en de waarde daarvan word bepaald door de locale die je hebt geselecteerd met .set_locale.

    In de tests die ik in het voorbeeld op http://www.globalize-rails.org/ heb gezet laat ik dit ook zien.

    Ook staat er nog ergens een voorbeeld op de wiki van een methode om de view vertalingen te kunnen ingeven zodat klanten dat zelf kunnen doen (i.p.v. gettext waar je ze eerst weer dingen moet uitleggen).

  2. procreate zei 104 dagen later:

    Deze bedoelde ik: http://globalize-rails.org/wiki/pages/example

(Laat url/e-mail achter »)

   Voorvertoning