Re: I need to LoadString() programmatically based on ID not Value

Tech-Archive recommends: Repair Windows Errors & Optimize Windows Performance


"Mihai N." <nmihai_year_2000@xxxxxxxxx> wrote in message news:Xns9C375D352551AMihaiN@xxxxxxxxxxxxxxxx
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

.

Relevant Pages

  • Re: 3vl 2vl and NULL
    ... >> Frank Hamersley wrote: ... >> the same entities and attributes to model, your UML diagrams would be ... >> We take data in from a screen as strings, ... >> the interface between dbms and humans (developers)? ...
    (comp.databases.theory)
  • Re: 3vl 2vl and NULL
    ... >> Frank Hamersley wrote: ... perhaps (somewhat similar to XML developers thinking in ... >> strings), but my reason in this case is that although you might cast to ... > Thirdly I have done the measuring over the last 25 years! ...
    (comp.databases.theory)
  • Re: Localized "Yes/No" strings
    ... Hmm, if this is is for posix compatibility, maybe somebody from MS Services for Unix ... I found just one system file with both yes/no and oui/non strings. ... Both are localized in 36 other languages, ... for the POSIX localization categories LC_COLLATE, LC_CTYPE, LC_MESSAGES, ...
    (microsoft.public.win32.programmer.kernel)
  • Re: GT.M V5.3-004A released
    ... Because Cache defaults to allowing a single global node to contain up ... Given that a lot of new GT.M developers are going to be experienced ... strings will increasingly become the norm in GT.M systems. ...
    (comp.lang.mumps)
  • Re: Myths of our time...
    ... But then in C you didnt have the string type at all. ... A more 'user friendly' approach would most likely have appeared if pragmatic developers where the ones defining the ... When I say normal, I mean normal for all> the languages I have used that support concatenation of strings with the> '+' operator, anyway. ...
    (borland.public.delphi.non-technical)