3 ms·
I’ve never worked on localization either, but I do spend a lot of time reading other people’s source code, and I always find it mildly annoying when a project u
by comex 3y ago
I’ve never worked on localization either, but I do spend a lot of time reading other people’s source code, and I always find it mildly annoying when a project uses identifiers because it means I have to grep twice: once for the message (to find the identifier) and once for the identifier (to find the code that uses it). In projects that embed messages directly, I only have to grep once.
I’ve wondered about the possibility of having the best of both worlds: have the source code contain the full English message (and no other identifier), but use a tool that automatically assigns identifiers to source code locations that contain messages. Different locations would get different identifiers even if they use the same string. The tool would have to be history-aware, in order to keep the identifier the same if the code is moved or if the message is edited. It would have to use heuristics to differentiate between “message was edited” and “message was deleted, and an unrelated message was added in roughly the same place”. But in practice this would usually be easy to do.
…Or you could simplify things drastically by having the source code contain both the English message and a unique identifier (perhaps just a number rather than anything descriptive). That’s less fun though.
- antipotoad 3y agoThe latter is roughly what we do on the project I work on: English string directly in the source, plus a human-readable identifier that helps translators understand the context of the string they’re translating. One script to extract all strings, and another to load all translations. Works fine really.
- avgcorrection 3y agoA double grep sounds easy to automate. FWIW I do the same thing in our code.