From: Joseph M. Newcomer on
I used to consider it to be a programming error to put any language-specific text in a
string in the source code, except for debug output messages. I now view debug output
messages with suspicion, and for products, ignore the fact that I could ever put a
language-specific literal string anywhere in the source code. EVERYTHING is now in the
STRINGTABLE.
joe

On Fri, 5 Feb 2010 09:48:21 -0800, "Tom Serface" <tom(a)camaswood.com> wrote:

>I absolutely agree about putting string resources in the resource file
>(especially in 2010 where it will be Unicode by default). I even put format
>strings in the resources now. I've been hit by the phrase, "Oh yeah we
>forgot to tell you, it also need to run in Japanese" too many times. My
>opinon:
>
>1. Always use Unicode
>2. Always use resource string table for any strings
>
>Tom
>
>"Giovanni Dicanio" <giovanniDOTdicanio(a)REMOVEMEgmail.com> wrote in message
>news:e9m$xEmpKHA.3792(a)TK2MSFTNGP06.phx.gbl...
>>> http://doc.trolltech.com/4.6/qstring.html
>>>
>>> it seems to me that QString offers a constructor which takes a const char
>>> *, but not a wchar_t*...
>>
>> Or to be more accurate, the QChar * (i.e. Unicode version) constructor
>> takes an additional size parameter:
>>
>> http://doc.trolltech.com/4.6/qstring.html#QString-2
>>
>> BTW: As Mihai several times wrote here, the best thing to do for
>> internationalization is to put string literals in resources instead of
>> embedding them in source code.
>>
>> Giovanni
>>
>>
Joseph M. Newcomer [MVP]
email: newcomer(a)flounder.com
Web: http://www.flounder.com
MVP Tips: http://www.flounder.com/mvp_tips.htm
From: Joseph M. Newcomer on
I find that dealing with embedded systems (as I have been doing all afternoon) I still
need ANSI characters at the periphery of my code (I use Unicode entirely inside the app)
joe

On Fri, 5 Feb 2010 09:50:37 -0800, "Tom Serface" <tom(a)camaswood.com> wrote:

>It wouldn't be very useful if it didn't support Unicode. Now if it didn't
>support ANSI, I'd guess not many people these days would care. Not
>supporting ANSI hasn't slowed down .NET any.
>
>Tom
>
>"Goran" <goran.pusic(a)gmail.com> wrote in message
>news:2e448c96-8106-49e4-8772-427d42e24d5e(a)c4g2000yqa.googlegroups.com...
>> On Feb 5, 1:28 pm, some dude <n...(a)no.com> wrote:
>>> I tried Qt the other day. QString AString = L"string"; was an error.
>>
>> So use a ctor with QChar. Did you try to suggest that Qt doesn't
>> support Unicode? Naaah... ( Docs were tl;dr, huh? ;-) )
>>
>> Goran.
Joseph M. Newcomer [MVP]
email: newcomer(a)flounder.com
Web: http://www.flounder.com
MVP Tips: http://www.flounder.com/mvp_tips.htm
From: Tom Serface on
I confess that I put log file info inline still, but I'm rethinking that
strategy. Still, my logs files are mostly for debugging and I can't read
anything except English and Spanish anyway. I find it cheaper to not have
to get all of those strings translated.

Tom

"Joseph M. Newcomer" <newcomer(a)flounder.com> wrote in message
news:657pm5p435reps209e7tgvm5uo1nif6cl6(a)4ax.com...
> I used to consider it to be a programming error to put any
> language-specific text in a
> string in the source code, except for debug output messages. I now view
> debug output
> messages with suspicion, and for products, ignore the fact that I could
> ever put a
> language-specific literal string anywhere in the source code. EVERYTHING
> is now in the
> STRINGTABLE.
> joe
>


From: Tom Serface on
Can't argue with that logic.

Tom

"Joseph M. Newcomer" <newcomer(a)flounder.com> wrote in message
news:fa7pm5lfiorknh0ev8vqisj2odp7rik4vh(a)4ax.com...
> I find that dealing with embedded systems (as I have been doing all
> afternoon) I still
> need ANSI characters at the periphery of my code (I use Unicode entirely
> inside the app)
> joe
>
> On Fri, 5 Feb 2010 09:50:37 -0800, "Tom Serface" <tom(a)camaswood.com>
> wrote:
>
>>It wouldn't be very useful if it didn't support Unicode. Now if it didn't
>>support ANSI, I'd guess not many people these days would care. Not
>>supporting ANSI hasn't slowed down .NET any.
>>
>>Tom
>>
>>"Goran" <goran.pusic(a)gmail.com> wrote in message
>>news:2e448c96-8106-49e4-8772-427d42e24d5e(a)c4g2000yqa.googlegroups.com...
>>> On Feb 5, 1:28 pm, some dude <n...(a)no.com> wrote:
>>>> I tried Qt the other day. QString AString = L"string"; was an error.
>>>
>>> So use a ctor with QChar. Did you try to suggest that Qt doesn't
>>> support Unicode? Naaah... ( Docs were tl;dr, huh? ;-) )
>>>
>>> Goran.
> Joseph M. Newcomer [MVP]
> email: newcomer(a)flounder.com
> Web: http://www.flounder.com
> MVP Tips: http://www.flounder.com/mvp_tips.htm

From: Hector Santos on
What we have in our pcode compiler is a text extraction into language
files which can then be used for translations. For example

Print [LoginPrompt "Enter your user name?"]

When this compiled, our compiler create *.PRM files, i.e,
LoginPrompt.prm, then all the *.PRM files are merged into a language
database file which customer can edit with a utility to create other
language database files.

The compiler adds op codes to function reference the "loginprompt"
index for the current logged in user language.

Worked very work for our console based applications. HTML is another
story and we recently had a discussion if we should employ the same
strategy for out stock HTML templates to help with single sourcing it.

In other words, we have stock dynamic HTML templates for various stock
client interfaces, Mail, Files, Chat, Who's Online, etc. For
different languages, people duplicate them and now we lose version
control. So we are looking at:

<td>Enter Your User Id</id>

We are looking at:

<td id="LoginPrompt">Enter Your User Id</id>

with some stock javascript and page initialization logic that will
change the innerHTML based on the user's language. The Javascript
could maybe use Ajax to go back to the server and use the original
database prompt language.

But as you said Tom, "its cheaper" not to have all those strings
translated and just allow individual operators to translate on their own.

Problem is that once you hold their hands, they expect EVERYTHING to
be automated for you. :)

--
HLS

Tom Serface wrote:

> I confess that I put log file info inline still, but I'm rethinking that
> strategy. Still, my logs files are mostly for debugging and I can't
> read anything except English and Spanish anyway. I find it cheaper to
> not have to get all of those strings translated.
>
> Tom
>
> "Joseph M. Newcomer" <newcomer(a)flounder.com> wrote in message
> news:657pm5p435reps209e7tgvm5uo1nif6cl6(a)4ax.com...
>> I used to consider it to be a programming error to put any
>> language-specific text in a
>> string in the source code, except for debug output messages. I now
>> view debug output
>> messages with suspicion, and for products, ignore the fact that I
>> could ever put a
>> language-specific literal string anywhere in the source code.
>> EVERYTHING is now in the
>> STRINGTABLE.
>> joe
>>
>
>