Internationalization in database

[Tarkin]

In een applicatie waar ik momenteel aan werk hebben we het volgende:

Een deel van de vertalingen komt uit de standaard resource bundles, een ander deel wordt opgehaald uit de database.
In die database hebben we dan aparte vertalingtabellen waar alle vertalingen inzitten. Voor de rest zit in die tabellen geen andere relevante data. Wel is er een wildgroei aan vertalingtabellen (we hebben een applicatie of 50 onder ons beheer die ook gebruik maakt van die tabellen + er zijn nog specifieke vertalingtabellen per applicatie)

Persoonlijk ben ik voor dit systeem niet te vinden.

* Je hebt 2 manieren om je data te vertalen
* het maakt het er niet eenvoudiger op om te zoeken waar een vertaling zit => tijdverlies voor iemand die dagelijks in die code werkt en quasi onmogelijk om het gemakkelijk uit te leggen aan een nieuwkomer
* Voor de database vertalingen is er een custom mechanisme geschreven om deze op te zoeken.

Mijn oplossing zou duidelijk zijn. Alle vertalingen uit de DB halen en verder aanvullen in de resource bundles. Alleen al de tijd die in de toekomst gewonnen gaat worden met zoeken zou deze optimalisatie rendabel maken.

Nu hebben mijn collegae meer een "meh" gevoel hierbij. Ze vinden het niet echt een probleem dat de vertalingen in de database zitten. Verdere argumenten hebben ze ook niet echt.

Ik vroeg me af wat jullie hiervan vinden. Als ik op het net rondkijk vind ik enkel artikels van pre 2006 (dus ook niet echt nuttig meer).

Ik moet er wel bijzeggen dat het om een applicatie gaat die begin 2000 geschreven is. En dat het dus miscchien in die tijd wel bon ton was om dit te doen.

[Hydra]

M.i. is de enige reden om dit via de DB te doen als het om content gaat die door (super)users aangepast kan worden. Zo niet zijn resource files, naar mijn mening, veel practiser. Ik denk dat in jouw geval het belangrijkste is om aan te kunnen tonen hoeveel werk het in de toekomst gaat schelen. Dus wanneer heb je een ROI. Dat is waar de meeste managers het meest in geinteresseerd zijn.

[Foeijonghaai]

Ik ben voor je technische mooiere oplossing.

Maar uit ervaring weet ik ook dat als je de enige bent die iets als probleem ziet, en je hebt je collegae nodig om het project uit te voeren, dat het trekken aan een dood paard is.

[Tarkin]

Het voordeel is dat ik momenteel als enige die applicatie onderhoud.

Ik vroeg me vooral af wat de beweegredenen hierachter zijn. Aleja, zaken zoals aanheftitels (die in een dropdown komen), om dat in de database te steken snap ik niet echt. De kost is toch altijd groter om dat op te halen uit de DB dan uit een property file?

[DJMaze]

Tarkin schreef op vrijdag 09 september 2016 @ 10:10:
De kost is toch altijd groter om dat op te halen uit de DB dan uit een property file?

Kan je met je file gebaseerde structuur meerdere talen tegelijk gebruiken?
Bijvoorbeeld: een e-mail naar de klant in Engels en een e-mail naar de beheerder in het Nederlands?

Ik gebruik zelf ook een database tabel per applicatie. Er is een performance impact, maar dat kan je goed reduceren als de ID kolom "binary" is.

Bij file based is er ook een probleem. Stel je hebt een bestand voor nieuws met daarin "Last %d replies".
Nu komt er een forum module bij met als taal string "Last %d replies".
Wat ga je doen?
A. de zelfde string op elke locatie opnieuw vertalen?
B. het "nieuws" bestand laden in forums zodat die vertalingen ook daar beschikbaar worden?
C. de string naar het algemene bestand verhuizen in elke taal?

Qua onderhoud is een database tabel dus makkelijker, maar langzamer.

Ik kies dus gewoon voor beide. Met name voor het complexe enkelvoud/meervoud in het Pools bijvoorbeeld.
Lees maar eens: https://www.gnu.org/softw...ml_node/Plural-forms.html

[ Voor 7% gewijzigd door DJMaze op 09-09-2016 10:34 ]

[Tarkin]

DJMaze schreef op vrijdag 09 september 2016 @ 10:31:
[...]

Kan je met je file gebaseerde structuur meerdere talen tegelijk gebruiken?
Bijvoorbeeld: een e-mail naar de klant in Engels en een e-mail naar de beheerder in het Nederlands?

Ik zie niet in waarom niet? Je gaat gewoon even van locale moeten switchen voor die 2e mail maar veel problemen zie ik daar niet in?

Ik gebruik zelf ook een database tabel per applicatie. Er is een performance impact, maar dat kan je goed reduceren als de ID kolom "binary" is.

Bij file based is er ook een probleem. Stel je hebt een bestand voor nieuws met daarin "Last %d replies".
Nu komt er een forum module bij met als taal string "Last %d replies".
Wat ga je doen?
A. de zelfde string op elke locatie opnieuw vertalen?
B. het "nieuws" bestand laden in forums zodat die vertalingen ook daar beschikbaar worden?
C. de string naar het algemene bestand verhuizen in elke taal?

Qua onderhoud is een database tabel dus makkelijker, maar langzamer.

Ik kies dus gewoon voor beide. Met name voor het complexe enkelvoud/meervoud in het Pools bijvoorbeeld.
Lees maar eens: https://www.gnu.org/softw...ml_node/Plural-forms.html

Ik snap niet goed met wat je hier bedoelt, maar resourcebundles kunnen toch ook allang met parameters werken? Dus of je dat nu in de DB steekt of in een resource bundle mag in principe geen verschil maken.

Als het je gaat om een string op 2 verschillende plaatsen te gebruiken? Daar zie ik ook geen problemen in aangezien resource bundles over het algemeen voor de hele applicatie is.


Wat er ook velen zeggen is dat het gemakkelijker is om veel algemene Strings maar op 1 plaats te vertalen. Dat is ook de hoofdreden dat ze het bij ons gebruiken. Ik moet helaas vaststellen dat de theorie en praktijk enorm verschillend is. Iedereen heeft een andere manier om bv persoonlijke coordinaten te benoemen. en er staan dus ontieglijk veel duplicaten in die tabellen (ook iets wat je niet echt wilt me dunkt).

We hebben dus naam, achternaam, verk_achternaam,... voor allemaal krak hetzelfde te zeggen.

[DJMaze]

Tarkin schreef op vrijdag 09 september 2016 @ 12:42:
Ik zie niet in waarom niet? Je gaat gewoon even van locale moeten switchen voor die 2e mail maar veel problemen zie ik daar niet in?

Ik schrijf een applicatie in C++ en die wordt volledig gelokaliseerd.
Ik draai die applicatie in het Nederlands en moet een e-mail sturen in het Pools, dan ga ik echt niet de hele applicatie in het Pools gebruiken. Want dat kan ik echt niet lezen, jij wel?
Hoe krijg jij dan alsnog een e-mail in het Pools?

[emnich]

Wat technisch de mooiste oplossing is, is niet zo relevant (buiten het feit dat er op basis van de informatie niet zo veel zinnigs over gezegd kan worden).

Waar het nu om gaat is hoeveel tijd het kost om het om te bouwen, hoeveel potentiële bugs ga je daarmee creëren en hoeveel tijd ga je in de toekomst besparen.

Als je schrijft dat het om 50 applicaties gaat dan vermoed ik dat je er niet aan moet beginnen...

[Tarkin]

DJMaze schreef op vrijdag 09 september 2016 @ 15:01:
[...]

Ik schrijf een applicatie in C++ en die wordt volledig gelokaliseerd.
Ik draai die applicatie in het Nederlands en moet een e-mail sturen in het Pools, dan ga ik echt niet de hele applicatie in het Pools gebruiken. Want dat kan ik echt niet lezen, jij wel?
Hoe krijg jij dan alsnog een e-mail in het Pools?

Hoe je het in C++ doet weet ik niet, maar in de java applicatie waar ik over spreek zou ik zeggen op het moment dat je de mail opbouwt de andere taal gebruiken van de resource bundle. Let op ik heb dit nog nooit gedaan wat je nu voorstelt dus dit is een aanname.

Jij gaat trouwens ook speciale calls naar de db moeten maken (of haal je alle vertalingen ineens op) als je de tweede mail in het pools wilt. Dus qua effort zal het nog steeds hetzelfde blijven. Qua kost zit je nog steeds met de DB calls.

offtopic:
je moet je trouwens ook niet aangevallen voelen. Van mij mag je gerust je vertalingen in de DB steken. Ik vroeg me gewoon af wat de echte pro's ervoor waren en ik heb ze nog niet gevonden. Toch niet voor een Java applicatie.

emnich schreef op vrijdag 09 september 2016 @ 15:19:
Wat technisch de mooiste oplossing is, is niet zo relevant (buiten het feit dat er op basis van de informatie niet zo veel zinnigs over gezegd kan worden).

Waar het nu om gaat is hoeveel tijd het kost om het om te bouwen, hoeveel potentiële bugs ga je daarmee creëren en hoeveel tijd ga je in de toekomst besparen.

Als je schrijft dat het om 50 applicaties gaat dan vermoed ik dat je er niet aan moet beginnen...

We hebben 50 applicaties maar het is een warboeltje van hoe de zaken gebruikt worden. Een deel in de DB een deel een aparte vertalingsservice (ja ze hebben de microservices ook ontdekt bij ons) en een heel groot deel resourcebundles.
Het voordeel dat ik heb is dat het een relatief kleine applicatie is (maar 5 frontend schermen, het is vooral een zwaar algoritme dat berekend en achteraf getoond wordt).

[DJMaze]

Ik voel me niet aangevallen hoor. Ik probeer gewoon wat "use-cases" en meer informatie te geven.
Met de gegeven informatie kan je zelf beslissen of alles in resources moet of een deel in 1 database tabel.

Ik gebruik voor simpele taalstrings een tabel

SQL:

CREATE TABLE translate  ( 
    msg_id  varchar(64) NOT NULL,
    v_en    longtext NOT NULL,
    v_nl    longtext NULL,
    PRIMARY KEY(msg_id)
)
ENGINE = MyISAM
CHARACTER SET utf8mb4
COLLATE utf8mb4_bin

Bestaat er geen vertaling in de resources doe een lookup in de tabel.
Bestaat hij nog steeds niet, maak deze aan in de tabel.

Hiermee vang ik alles af en kan ik alsnog data uit de tabel verhuizen naar resources.

[Rotterdammertje]

Is het niet handiger om een tabel met msg_id, locale en message te maken? Dan hoef je niet je tabelstructuur aan te passen als je een taal wil toevoegen.