Re: I need to LoadString() programmatically based on ID not Value
"Mihai N." <nmihai_year_2000@yahoo.com> wrote in message
news:Xns9C375D352551AMihaiN@207.46.248.16...
On the other side, strings IDs are not managed *at all* by the IDE
....
True, although this does not cause many problems in real life due to the
English file also using the string constants, and if there was a
misspelling, it would be caught in the English as well.
Not of there is a weird error that you rarely see.
Yes, I can understand that. String ID's have downsides, but so do numeric
ID's.
I really don't understand what "maintenance" is needed for numeric IDs.
Essentially, any and all required manipulation of resource.h. Who hasn't
spent at least some time in resource.h?
The tr() macro allows you to specify a string for the
context, as well as full-blown comments to the localizer, to keep these
things straight.
A feature that many developers don't use.
With respect, developers who don't use the context are the same developers
who would attempt to re-use the same resource ID for another context. So
the problem is the same, it is no more pervasive the Qt way than with
traditional resource id way.
I will admit that I've reused a few ID's in my time...
Plus, a proper string for context will end up being almost an ID
(how do you make sure that the "Scan" button that scannes the disk is
not merged with the "Scan" button to scan a page? Or that the "New"
button to create a new file (masculin in most latin languages) is not
the same as the "New" button to create a new page (usually feminin))
Here Qt actually gives you more room by having a special comment you can use
to discuss such things with the translator. No such comment space is
provided in a traditional .rc file stringtable. And the comment goes right
next to the usage of the string (in the source code) and not in some other
file, so you don't have to manipulate separate .rc files during development.
Strings should never-ever be merged. You will have to speak the 30
target languages to be sure (and you know nothing about language 31
that the sales guys will ask for next year).
Perhaps not, but the same merging occurs when using .rc files as well. It's
an educational thing, not a superiority of .rc files. And you are probably
right that strings should "never-ever" be merged, but then why do
translation memory programs make it so easy to reuse these strings? A
bragging feature of them is that they will search the database for
pre-existing words and phrases and re-use them for new strings....
You might say "these are isolated cases", but when you get a pretty
big software and you translate it into 20-30 languages, then it is
almost sure you will see this problems.
....
Many developers don't believe this.
But unfortunately I know only two ways to convince:
1. work for at lease one year in localization "for real"
(not have your product localized, but work in a l10n company)
2. trust someone who knows
Your word is absolutely correct for one scenario. But its important to use
the right tool for the job. What is essential for Adobe Reader (millions of
users, many languages, huge software) does not necessarily serve smaller
projects with fewer users and less languages. You have to see the big
picture. A product's success is not dependent only on how well it is
localized. Things like fast development, stability, speed, and
deployability (which are not necessarily trademarks of Adobe Reader, no
offense) are also critical. So if a localization scheme is less accurate
(but is not necessarily so) and is more productive to use, it is not
necessarily a bad thing. I've successfully used .h/.rc files, string ID XML
files, and am about to deploy a Qt app, and for my needs I have to say that
the Qt app provides beautiful localization tools and lets me keep strings in
my code, as any developer would prefer.
Oh, and Qt does not require the silly _T() macro either! So embedded
strings are truly simple again. (Yet strings are full UTF-16).
-- David