Posted: 24 Aug 2006 15:13
I've implemented it now, basically following my above suggestion except limiting action 13 to only GRF-specific strings, i.e. the D000/DC00 ranges. Other IDs should be set with a regular action 4, that way there'll be the least duplication of code.
While I've written the specs for this, I noticed that it might be useful to have a language ID byte after all, like in action 4. Should I add it? In principle, the translation GRF can check the language via action 7 and deactivate itself if it's the wrong language. This might in fact be preferable because then it'll appear as deactivated in the GRF Status Window (in the patch at least, no idea about OTTD), whereas if the action 13 is just skipped because it's the wrong language, the GRF will appear active but won't in fact change any strings.
I'm open to changing this though, let me know what you think.
While I've written the specs for this, I noticed that it might be useful to have a language ID byte after all, like in action 4. Should I add it? In principle, the translation GRF can check the language via action 7 and deactivate itself if it's the wrong language. This might in fact be preferable because then it'll appear as deactivated in the GRF Status Window (in the patch at least, no idea about OTTD), whereas if the action 13 is just skipped because it's the wrong language, the GRF will appear active but won't in fact change any strings.
I'm open to changing this though, let me know what you think.