Hoi,
Zo'n twee jaar geleden heb ik een Macintosh applicatie gepoort naar Windows. Toendertijd hebben we besloten om de vertalingen maar even te laten voor wat het was, en het programma af te krijgen. Die vertalingen is nu precies iets waar we tegenaan lopen in Frankrijk. Nu ben ik alleen niet helemaal zeker wat de beste, en mooiste oplossing is op korte en lange termijn.
Satellite DLL
Ik heb wat rondgezocht, en naar mijn mening is een aparte DLL voor de vertalingen de mooiste oplossing. Nu werd er meerdere keren verwezen naar het feit om een satellite DLL te maken. Het idee daarvan is dat de complete resource van de applicatie wordt gekopieerd naar de DLL, en daar dus volledig wordt aangepast voor een specifieke taal (als ik het allemaal goed heb begrepen).
Voordelen:
Het alternatief is om alle strings die gebruikt worden in een stringtable zetten van een aparte DLL (of tekstfile wat mij betreft). Vervolgens zou ik dan de juiste DLL mee moeten leveren, en bij elk dialoog de labels etc. de text aanpassen naar wat er terugkomt uit de DLL.
Voordelen:
Zo'n twee jaar geleden heb ik een Macintosh applicatie gepoort naar Windows. Toendertijd hebben we besloten om de vertalingen maar even te laten voor wat het was, en het programma af te krijgen. Die vertalingen is nu precies iets waar we tegenaan lopen in Frankrijk. Nu ben ik alleen niet helemaal zeker wat de beste, en mooiste oplossing is op korte en lange termijn.
Satellite DLL
Ik heb wat rondgezocht, en naar mijn mening is een aparte DLL voor de vertalingen de mooiste oplossing. Nu werd er meerdere keren verwezen naar het feit om een satellite DLL te maken. Het idee daarvan is dat de complete resource van de applicatie wordt gekopieerd naar de DLL, en daar dus volledig wordt aangepast voor een specifieke taal (als ik het allemaal goed heb begrepen).
Voordelen:
- De dialogen zijn compleet aangepast voor die taal, zodat je niet rekening hoeft te houden met meer ruimte in je dialogen (wat raar eruit kan gaan zien). Een mooie oplossing dus
- Geen extra code in de InitDialog functies
- Als de resource wordt aangepast (dialoog erbij, of label erbij, etc.), dan zou dat voor elke taal gedaan moeten worden. Dat betekent dus op de lange termijn meer werk.
Het alternatief is om alle strings die gebruikt worden in een stringtable zetten van een aparte DLL (of tekstfile wat mij betreft). Vervolgens zou ik dan de juiste DLL mee moeten leveren, en bij elk dialoog de labels etc. de text aanpassen naar wat er terugkomt uit de DLL.
Voordelen:
- De resource hoeft niet meerdere keren te worden aangepast bij een wijziging
- De resources moeten zo opgezet zijn dat alle strings erin passen. Het zou dus kunnen dat een label voor de Engelse versie een grote lege ruimte krijgt omdat de Nederlandse versie meer ruimte nodig heeft
- Veel werk op korte termijn, omdat ik dan nu alle dialogen langs moet gaan om per label etc. de juiste text te laden
- De ini file met de te vertalen strings wordt steeds overschreven, dus lastig bij een wijziging als het grootste deel al is vertaald
- De output resource file wordt ook steeds overschreven, waardoor het voordeel van een aangepaste interface compleet verloren gaat
"There are 10 kinds of people in the world, those who understand binary and those who don't" | Werkbak specs