4 ms·

Just a simple hash table, or if you prefer, a red-black tree. The index where the string was found would be the same between the native list and locale string f

by byuu 11y ago

Just a simple hash table, or if you prefer, a red-black tree. The index where the string was found would be the same between the native list and locale string file. I like this style because a) if the locale file is deleted you don't end up with no text in your app, b) you don't need a gigantic pool of cryptic IDs, c) it's more intuitive what you're trying to print in the source code. print(tr("Warning: changing the video driver requires a restart to take effect")); //vs print(tr(TR_WARN_VIDEO_DRIVER_CHANGE_RESTART)); You'll create the English locale file anyway for others to translate for you, and you can even use that. The two major downsides are a) sometimes the same sentence is used in two areas and has the same translation in one language, but different translations in another (very rare), and b) if you change the text wording later, you have to edit it in the source code instead of in a separate English locale file. > Since we're talking about performance, I wonder why people write it this way. You're doing something horrendously wrong if your application spends even 0.1% of its time looking up strings to put into GUI windows.

TeMPOraL 11y ago
> a) sometimes the same sentence is used in two areas and has the same translation in one language I suspect it's not that rare of a thing, it would explain at least some of the bad translation cases I've seen, that are the reason I never use software in my native language if I can avoid it. > b) if you change the text wording later, you have to edit it in the source code instead of in a separate English locale file. And, if I understand correctly, in every other locale file too. This tingles my DRY sense in a bad way. > You're doing something horrendously wrong if your application spends even 0.1% of its time looking up strings to put into GUI windows. True. Though you can use this reasoning for pretty much every single thing in the source code, and this way lies Java and XML. Premature optimization may be bad, but I still try to always pick the faster option when it doesn't require too much work :).
- byuu 11y ago
  > And, if I understand correctly, in every other locale file too. This tingles my DRY sense in a bad way. Not as long as your locale file is ordered the same for each region. Then the index match on the English string tells you which line to read from. > Premature optimization may be bad, but I still try to always pick the faster option when it doesn't require too much work :) Certainly. It's definitely a balancing act. But I think I give up maybe ~5% total performance for a ~500% improvement in code clarity. Moving to Java and things like that would increase the overhead by an order of magnitude while probably not helping readability at all (maybe just a little.) Of course, if I were trying to parse a 20GiB text file, I'd probably be working on it via mmap() over a char* array :D

by byuu 11y ago

TeMPOraL 11y ago

> a) sometimes the same sentence is used in two areas and has the same translation in one language I suspect it's not that rare of a thing, it would explain at least some of the bad translation cases I've seen, that are the reason I never use software in my native language if I can avoid it. > b) if you change the text wording later, you have to edit it in the source code instead of in a separate English locale file. And, if I understand correctly, in every other locale file too. This tingles my DRY sense in a bad way. > You're doing something horrendously wrong if your application spends even 0.1% of its time looking up strings to put into GUI windows. True. Though you can use this reasoning for pretty much every single thing in the source code, and this way lies Java and XML. Premature optimization may be bad, but I still try to always pick the faster option when it doesn't require too much work :).

byuu 11y ago
> And, if I understand correctly, in every other locale file too. This tingles my DRY sense in a bad way. Not as long as your locale file is ordered the same for each region. Then the index match on the English string tells you which line to read from. > Premature optimization may be bad, but I still try to always pick the faster option when it doesn't require too much work :) Certainly. It's definitely a balancing act. But I think I give up maybe ~5% total performance for a ~500% improvement in code clarity. Moving to Java and things like that would increase the overhead by an order of magnitude while probably not helping readability at all (maybe just a little.) Of course, if I were trying to parse a 20GiB text file, I'd probably be working on it via mmap() over a char* array :D