Re: Substituting the main menu bar(s)
David Webber wrote:
"David Wilkinson" <no-reply@effisols.com> wrote in message
news:OquihpXiGHA.1204@TK2MSFTNGP02.phx.gbl...
(b) the realisation that as (i.a.) their cancel buttons show "Annuler"
anyway (thanks to MFC) the program was already partly translated, and
that therefore "gradual translation" was not going to be the sin I had
thought it to be;
David:
Is this true? I know it is true for property sheet buttons (because they
are not in the .rc file), and of dialogs like the open file dialog (which
come from the operating system) but is it true of dialog buttons? Surely
not (their text is specified in the .rc file).
You're right - I think in all cases. But I suspect it is also true for
message boxes.
Personally, I do not like this feature. If my app is in English, I would
like everything to be in English, partly because my user guide is in
English. In fact, I deliberately set the text of property sheet buttons to
English in order that my help system matches the actual application.
I never bothered with this, but I may do in future. Do you just set the
text of the buttons in using their standard control ID? Where do you do
it? From the OnInitDialog of the property sheets?
By the way, what do you do to test the French version of your app? Do you
have a real French version of Windows on another machine, or do you change
your settings? Or neither?
At the moment I ask my tester friend in France :-)
But because I am translating all *my* RC files, all I need do is switch to
French and check where *my* translation Cancel->Annuler does not happen and
then I have a good idea where it won't happen the other way!
[I do set the keyboard to various languages sometimes, to test keyboard
shortcuts. But that is different. In particular I had problems with
shortcuts once with keys 0-9 as on some keyboards they use the Shift key.
And I use things like > as shortcuts (for accents that look like > and
against Microsoft's advice) so it needs careful testing.]
Dave
Hi Dave:
Yes, for my property sheets I use the ID's to set the button texts to
the English values in the OnInitDialog of the sheet. But I do not (yet)
try to do anything about other strings that might be displayed in the
language of the operating system.
Let me be sure that I understand what you do exactly. You have an Excel
sheet that has a column for each language. If I understand correctly,
this functions as a dictionary, where the "key" is the English string,
not the resource ID. I had thought of doing that also, but to use it for
"last-minute-on-the-fly-substitution" rather than compile time
generation of a .rc file.
I think that the reason you do it this way is that all strings in the
..rc file are treated equally, whether they be menu text, control text,
tooltip text, text for a message box, anything. You just look the
English text up in the dictionary, and substitute it in the .rc file.
This was my motivation also (but in a different context); the English
string could come from anywhere -- the .rc file, from the back-end of my
application, or even from hard coded strings (a habit I have never
broken myself of, I'm afraid).
You mention one disadvantage of your dictionary to be that each English
string can only have one translation. Another, it seems to me, is that
if you change the English text (even in some trivial way) then you have
to modify your dictionary. If your dictionary were keyed to resource
ID's this would not happen. But then you would have trouble with things
like menu items, which have two strings associated with them: the menu
text and the tooltip text. But you could get around this by having two
dictionaries (both keyed to resource ID's); one for menu/control text
and another for tooltip text. It would complicate making the
substitutions in the .rc file, but it would not be very hard. In this
case, the strings in the original .rc file could become placeholders,
because English could be treated the same as every other language. Every
string in every language could come from your two Excel dictionaries.
David Wilkinson