Toon posts:

i18n, l10n en database content

Pagina: 1
Acties:

Acties:
  • 0 Henk 'm!

Verwijderd

Topicstarter
Ik ben bezig aan een applicatie in php die ik graag i18n op wil zetten. Nu loop ik tegen een vraagstuk aan waarvan ik niet weet wat Best Practice is, en ik kan er eigenlijk vrij weinig info over vinden.

Het probleem zit hem in het localiseren van content en de opbouw van de database structuur. Als voorbeeld wil ik graag 'Product' aandragen. Het is allemaal nog vrij simpel als je alleen verschillende talen wilt hanteren, maar het wordt lastiger als je ook nog de dimensie landen erbij pakt. Zeg maar 'nl/fr' vs 'nl_BE/fr_BE' cultures.

Op dit moment heb ik 2 tabellen voor Product;

product
-- id
-- code
-- dimensions

product_i18n
-- id
-- culture
-- name
-- description
-- price


Dit lijkt me een vrij logische opbouw. Culture kan dan bijvoorbeeld nl, fr, en, de bevatten, maar ook nl_NL, fr_BE, nl_BE, de_DE. Echter vraag ik me af of ik niet bijvoorbeeld '-- price' in de product tabel moet plaatsen en deze tabel moet uitbreiden met '-- country'. Culture wordt dan eigenlijk gewoon language.

Prijzen en andere attributen van een product kunnen per locatie (regio/land) verschillen.

Ik denk dat er voor elke oplossing wel wat te zeggen valt, maar ik ben eigenlijk op zoek naar wat best practices en succesverhalen van mensen die hier mee te maken hebben gehad. Ik kom met google niet echt verder dan wat artikelen over taallabels en database content in verschillende talen, maar nooit een combinatie met gelocaliseerde content.

Acties:
  • 0 Henk 'm!

  • samo
  • Registratie: Juni 2003
  • Laatst online: 26-09 20:33

samo

yo/wassup

Werk je met Symfony? Er wordt namelijk een verschil gemaakt tussen i18n (droog gezegd meer talen aanbieden) en L10n (ook zorgen dat de eenheden en vorm passen bij de locatie). Dus wil je de schrijfwijze aanpassen, dan kan je de L10n-helper gebruiken begreep ik uit het Cookbook, maar als je per land echt verschillende prijzen wilt kijk je weer naar een aparte tabel.

Bekend van cmns.nl | ArneCoomans.nl | Het kindertehuis van mijn pa in Ghana


Acties:
  • 0 Henk 'm!

Verwijderd

Topicstarter
Ik gebruik geen symfony, maar wel een framework (eigen) dat vergelijkbaar is. Overigens vindt ik de documentatie van symfony vrij summier.

Het gaat me inderdaad om het aanbieden van localized content uit de database. Mijn vraag betreft eigenlijk het inrichten van die database op een zinnige manier die beheersbaar is, en ben daarom eigenlijk benieuwd naar ervaringen van users die met hetzelfde bijltje hebben gehakt.

Het versleutelen van labels, schrijfwijze en eenheden aanpassen staan hier verder even buiten :)

[ Voor 10% gewijzigd door Verwijderd op 02-12-2008 17:38 ]


Acties:
  • 0 Henk 'm!

  • djc
  • Registratie: December 2001
  • Laatst online: 08-09 23:18

djc

samo schreef op dinsdag 02 december 2008 @ 17:30:
Werk je met Symfony? Er wordt namelijk een verschil gemaakt tussen i18n (droog gezegd meer talen aanbieden) en L10n (ook zorgen dat de eenheden en vorm passen bij de locatie).
Volgens mij draai je hier de termen om: Wikipedia: Internationalization and localization.

Rustacean


Acties:
  • 0 Henk 'm!

  • kenneth
  • Registratie: September 2001
  • Niet online

kenneth

achter de duinen

Het is niet alleen het omdraaien: i18n is het inbouwen van de mogelijkheid tot L10n, waar L10n het concrete aanpassen naar een bepaalde locale is.

Look, runners deal in discomfort. After you get past a certain point, that’s all there really is. There is no finesse here.


Acties:
  • 0 Henk 'm!

Verwijderd

Topicstarter
Ik waardeer jullie reacties, maar het gaat mij niet om de definitie van i18n en L10n hè :)

Acties:
  • 0 Henk 'm!

  • BalusC
  • Registratie: Oktober 2000
  • Niet online

BalusC

Carpe diem

Is de prijs voor elk land daadwerkelijk verschillend, of is de prijs afhankelijk van de huidige koers van de lokale munteenheid ten opzichte van een vaste munteenheid? Indien het eerste, dan zou ik het in de i18n tabel stoppen (alhoewel ik dat wellicht niet in de praktijk zou doen, maargoed, het gaat om de tabellen dat je hier aanbiedt). Indien het tweede, dan zou ik het gewoon in de Product tabel gooien.

Acties:
  • 0 Henk 'm!

  • MSalters
  • Registratie: Juni 2001
  • Laatst online: 13-09 00:05
Taal en land zijn volledig gescheiden dimensies. nl_BE is dus ook geen verwijzing naar belgie, maar naar vlaams. Je mag best defaults erop baseren, maar ga geen VAT rekenen of dimensies in inches uitdrukken omdat iemand en_GB als taalvoorkeuze heeft ingesteld.

Man hopes. Genius creates. Ralph Waldo Emerson
Never worry about theory as long as the machinery does what it's supposed to do. R. A. Heinlein


Acties:
  • 0 Henk 'm!

Verwijderd

Topicstarter
MSalters schreef op woensdag 03 december 2008 @ 20:04:
Taal en land zijn volledig gescheiden dimensies. nl_BE is dus ook geen verwijzing naar belgie, maar naar vlaams. Je mag best defaults erop baseren, maar ga geen VAT rekenen of dimensies in inches uitdrukken omdat iemand en_GB als taalvoorkeuze heeft ingesteld.
Ik dacht dat je juist wel mocht aannemen dat BE naar belgie zou verwijzen. Zie bijvoorbeeld even de ups.com site. Daar selecteer je ook nederlands - Nederland bijvoorbeeld en in je url vind je dan /nl/nl..

Wat is jouw suggestie om het land als dimensie erbij op te slaan?

Acties:
  • 0 Henk 'm!

  • samo
  • Registratie: Juni 2003
  • Laatst online: 26-09 20:33

samo

yo/wassup

Ik denk dat MSalters bedoelt dat je een onderscheid moet maken tussen interface-language, en geografische locatie.

Bekend van cmns.nl | ArneCoomans.nl | Het kindertehuis van mijn pa in Ghana

Pagina: 1