[Lazarus] Improving IDE Internationalization

dmitry boyarintsev skalogryz.lists at gmail.com
Sun Jan 24 14:22:22 CET 2010


On Sun, Jan 24, 2010 at 4:50 PM, Marcelo B de Paula <marcbp at terra.com.br> wrote:
> The fact that current code is comparing messages with const strings like
> "Note:" prevent the use of
> translated compiler messages. Instead, the use of message numbers (compiler
> switch -vq) can be
> used in place to detect the type of message. So we could use the message
> number itself or the type.

You're right the current implementation is aimed to be working with
FPC prior to 2.2.4, so -vq is not used.

Instead a translated error prefix is used. The translated prefix is
always provided in .msg file (see 01012..01016  messages in .msg).
Since a messages are always constructed in the way: PREFIX+MESSAGE.
It's quite safe to determine the message time by searching the
translated prefix.

See main.pp:10312 the translated prefixes are used:
        for err := Low(TFPCErrorType) to High(TFPCErrorType) do
          with Project1.CompilerOptions.CompilerMessages do
            TheOutputFilter.ErrorTypeName[err] := ErrorNames[err];

OutputFilter.ErrorTypeName is later used to determine the proper type
of the message.
It can be said, that OutputFilter "translates" a human language
message type to english (FPCErrorTypeNames array).

So later a check

CurrentMessageParts.Values['Type']:='Note';//FPCErrorTypeNames[etNote];

works fine, because CurrentMessageParts always contain English error
type names (translated by Outputfilter).

----

Anyway. What i'd like to say is that current implementation is working
with both 2.2.4 and 2.4.0 (or later) versions of the compiler. And
supports translated messages correctly.

Of course, using messages number instead of prefix parsing would be
really nice (and clean), though would break backward compatibility
too.

Should it be fixed, if not broken?

thanks,
dmitry




More information about the Lazarus mailing list