Localization van een MFC applicatie

Pagina: 1
Acties:

  • ^Mo^
  • Registratie: Januari 2001
  • Laatst online: 04-11-2025
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:
  • 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
Nadelen:
  • 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.
DLL met string table
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
Nadelen:
  • 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
Zoals misschien wel een beetje te proeven is uit mijn post, gaat mijn voorkeur toch wel wat meer richting de eerste optie. Echter ik ben een beetje bang dat het op de lange termijn meer werk, of fouten gaat opleveren omdat ik misschien een resource vergeet aan te passen voor een bepaalde taal. Ik heb wel een gratis tooltje gevonden op CodeProject, LocalizeRC. Deze haalt alle strings uit een resource en bouwt na vertaling weer een nieuwe resource. Dat scheelt wel wat werk, maar daar kleven toch ook een aantal nadelen aan:
  • 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
Misschien zit ik wel in de compleet verkeerde richting nu te zoeken, en zijn er veel makkelijkere alternatieven voor localization. Het is belangrijk dat het op de lange termijn voor niet veel werk zorgt, zodat het maken van fouten minimaal is. Als we er te veel handelingen voor moeten doen dan gaat dat zeker weten voor problemen zorgen.

"There are 10 kinds of people in the world, those who understand binary and those who don't" | Werkbak specs


  • LordLarry
  • Registratie: Juli 2001
  • Niet online

LordLarry

Aut disce aut discede

Een niet gratis tooltje die hier speciaal voor gemaakt is Multilizer

We adore chaos because we like to restore order - M.C. Escher