| Translating Script Names
|
|---|
Date: 7/6/2007
| So Scribe has script files stored in the "Scripts" sub-folder and at the moment they show up in the tools menu. There are several problems to be addressed. First of all the name of the command is currently just the file name. But then means it can't be translated into all the different languages that Scribe supports. Currently translations for the existing commands are in the Scribe.lr8 file which gets loaded at runtime. However there needs to be a mechanism that associates a given string resource with the Script file.
I'm considering several possibilies. None of which are particularly palettable.
- Embed the translation ID in a header of the script. Pros: nothing specific, Cons: You have to read the file at startup. Lots of scripts could be slow. Bit fragile if the ID number changes (rare but possible).
- Embed the translation ID in the filename of the script. Better than the first option but still can break if the ID changes.
- Embed the symbol define in the filename. Pros: very unlikely to break, the symbol doesn't change. Cons: Current resource runtime code doesn't store the define symbol, so I'd have to store that and it'd take up memory.
- Embed the translation directly into the script file. Pro: nice and self contained, never breaks. Con: Will get overlooked by translators and never updated.
- Something else?
I'd like some feedback or ideas. The translation has a reference number (int), an ID (int) and a define (string name). The ref is unique, the ID is the same for all strings with the same define.
|
| Comments:
|
kobi
07/06/2007 7:02am
| you can have a simple db, with the matching translation for each word or phrase.
when changing interface to this language, it will try to replace the default filename with the translation unless there isn't one.
(in your case, on startup it will list the filenames, find translations for this language, and cache them)
I think it's a pretty obvious solution.
it will read the db once for every name. (but doesn't have to happen every launch because it can be cached, and check for updated files on idle time or every few hours in a background thread (db will contain timestamp to compare))
ofcourse it may be overkill for the current situation, since you don't have thousands of translation strings.
hth, kobi
|
|
|
| Reply
|
|---|
| From:
|
|
| Email (optional):
|
(Will be HTML encoded to evade harvesting)
|
| Message:
|
|
|
|
|
|
|
|
|
|
