Sign in Join

Live chat for Free Pascal, Lazarus, Delphi and every Pascal programmer.

Mailing lists / lazarus / 2010-01

Improving IDE Internationalization

19 messages · 5 people · –

Reply by email Subscribe to this list Your subscription

Read-only archive. Use j and k to move between messages.

Marcelo Borges de Paula

Happy new year to everyone.

I?m having some troubles when using other compiler messages files to compile Lazarus or when using fpc compiled with other message file language than english. The fact is that Lazarus IDE has some pieces of code with embedded strings constants. I thought the most common way to solve problems like this was to declare an identifier to it and moving it to resourcestring header (or file, i.e. LazarusIDEstrconsts)

*** The question is : What should be moved or not moved there ???? ***

Other situation occurs with constant string in logic, like this example from msgview.pp

procedure TMessagesView.MessageViewDrawItem(Sender: TCustomTreeView;
  Node: TTreeNode; State: TCustomDrawState; Stage: TCustomDrawStage;
  var PaintImages, DefaultDraw: Boolean);
var
  TheText: string;
  ARect: TRect;
const
->  cHint         = 'Hint: User defined:';
->  cNote         = 'Note: User defined:';
->  cWarning      = 'Warning: User defined:';
  clMsgHint     = clBlue;
  clMsgNote     = clGreen;
  clMsgWarning  = clRed;
  cLeftSpacer   = 0;
  procedure ChangeFontColor(c: TColor);
[-] ...
  end;
begin
  if StagecdPostPaint then exit;
  // a paint means, something has changed (scrolling, expand, collapse, resize, ...)
  Changed;
  //DebugLn(['TMessagesView.MessageViewDrawItem Index=',Node.Index,' Count=',MessageTreeView.Items.Count,' TheText="',TheText,'"']);
  { Only use custom colors if not selected, otherwise it is difficult to read }
  if not (cdsSelected in State)
  then begin
->    TheText := Node.Text;
->    if Pos(cNote, TheText) > 0 then
->      ChangeFontColor(clMsgNote)
->    else if Pos(cHint, TheText) > 0 then
->      ChangeFontColor(clMsgHint)
->    else if Pos(cWarning, TheText) > 0 then
->      ChangeFontColor(clMsgWarning);
  end;
end;
   If i use other language the code above will not work, since messages are translated.

I?m trying to figure how to solve this one, but before start sending patches maybe should be wise to hear what others have to say.
Maybe we get some guidelines on how to proceed in such situations.

Regards,

Marcelo.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lazarus.freepascal.org/pipermail/lazarus/attachments/20100101/27d4578b/attachment-0001.html>

Reply by email

Mattias Gaertner
to Marcelo Borges de Paula
Show quoted text 7 lines
Happy new year to everyone. I?m having some troubles when using other compiler messages files to compile Lazarus or when using fpc compiled with other message file language than english. The fact is that Lazarus IDE has some pieces of code with embedded strings constants. I thought the most common way to solve problems like this was to declare an identifier to it and moving it to resourcestring header (or file, i.e. LazarusIDEstrconsts)

I think there is a better way:

http://wiki.lazarus.freepascal.org/IDE_Development#Translated_compiler_messages

[...] Maybe we get some guidelines on how to proceed in such situations.

I added some todos.

Mattias

Reply by email

Marcelo B de Paula
Mattias wrote 7 lines
I think there is a better way: http://wiki.lazarus.freepascal.org/IDE_Development#Translated_compiler_messages I added some todos. Mattias

Ok. I understand that will take some time to acomplish these todos. I?ll see what i can do to help.

What about the embedded strings in code. Is there any rules to follow ?

Regards

Marcelo.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lazarus.freepascal.org/pipermail/lazarus/attachments/20100102/e6d80a89/attachment.html>

Reply by email

Marcelo B de Paula

Well, for a few days now i'm trying to acomplish this:

http://wiki.lazarus.freepascal.org/IDE_Development#Translated_compiler_messages

I already have a new TOutputFilter working, but unfortunatly just tested on win32.
I will need some help to test this in other plataforms. Some problems appeared during this modification that i want to share. Any comments and suggestions are welcomed.

- Using TBaseCompilerOptions.CompilerMessages to locate messages by its number.
Problems:
- Loading Errors and Fatal errors from compiler message file (errore.msg).
Needed to change CompilerOptions.pp to load 'E' and 'F' types.
- The default message table is a problem. It is hardcoded and it need the types 'E' and 'F' of
messages.
The compiler messages file is growing, so its a matter to update this code every time we
have new compiler messages. IMHO, the default messages should be loaded from disk
(errore.msg).
- Now on CompilerOptions must be valid to TOutputFilter work.
- The Project Options->Compiler Options->Messages should be tunned to not present 'E'
and 'F' types.

- Compiler.pp should include "-vq" option in cmdline.

Other problem is regarding to build lazarus from IDE. Since BuildLazDialog uses external
tools to create Lazarus, no CompilerOptions is assigned at that time. So TOutputFilter not
work properly. As a work around, its displaying all messages.

At this point, i didn?t touched the QuickFixItems.

If anyone wants the code to test or evaluate, please just ask and I?ll send it.
Of course, if anyone has more ideas in this subject, feel free to argue.

Marcelo.

Reply by email

dmitry boyarintsev
to Marcelo B de Paula

Hello Marcelo,

The current (svn version) of Lazarus, is working as described. Except for messages are not loaded from errore.msg file initially. The location of errore.msg may vary from platform to platform, depending on location of FPC.
But IDE's compiler messages can be configured to load the messages file by default, from a specified location.

Marcelo B de Paula wrote
? ? ?Needed to change CompilerOptions.pp to load 'E' and 'F' types.

It's not necessary to load E/F it should NOT
be possible to "switch them off", as you say it yourself:

? ?- The Project Options->Compiler Options->Messages should be tunned to not present 'E' and 'F' types.

The only tweak required here was to load translated "error", "fatal error" strings, so the OutputFilter could detect the type of the error and shown the proper Icon. It has been implemented a few months ago.

thanks,
dmitry

Reply by email

dmitry boyarintsev
to Marcelo B de Paula: Hello, dmitry I don?t think that Lazarus is working as this.…
Marcelo B de Paula wrote 6 lines
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

Reply by email

Marcelo B de Paula
to dmitry boyarintsev: The current (svn version) of Lazarus, is working as described. Except for messages are…

Hello, dmitry

I don?t think that Lazarus is working as this.
http://wiki.lazarus.freepascal.org/IDE_Development#Translated_compiler_messages was added recently by Mattias

The purpose of new code is substitute the error string treatments by the message numbers
As an example see this excerpt:

  function CheckForNoteMessages(p: integer): boolean;
  begin
    Result:=false;
    if CompStr('Note: ',s,p) or CompStr(FErrorNames[etNote], s, p) then
begin
      DoAddFilteredLine(copy(s,p,length(s)));
      fLastErrorType:=etNote;
      CurrentMessageParts.Values['Stage']:='FPC';
      CurrentMessageParts.Values['Type']:=FPCErrorTypeNames[fLastErrorType];
      Result:=true;
      exit;
    end;
  end;

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.
See example:

    case msg of
       //
       //
       //   Lines compiled
       1008: begin
              if (CompilerOptions.ShowAll or CompilerOptions.ShowSummary)
then
                  DoAddFilteredLine(copy(s,1,length(s)));
              Result:=true;
       end;
  case CompilerMsgType of
     // Note
     'N' : begin
            //
            fLastMessageType:=omtFPC;
            fLastErrorType:=etNote;
            CurrentMessageParts.Values['Stage']:='FPC';
            CurrentMessageParts.Values['Type']:='Note';//FPCErrorTypeNames[etNote];
            //
            SkipMessage:=not (CompilerOptions.ShowNotes or
CompilerOptions.ShowAll);
            if not SkipMessage then DoAddFilteredLine(s);
            Result:=true;
     end;
Earlier message 30 lines
----- Original Message ----- From: "dmitry boyarintsev" To: "Lazarus mailing list" Sent: Sunday, January 24, 2010 2:39 AM Subject: Re: [Lazarus] Improving IDE Internationalization Hello Marcelo, The current (svn version) of Lazarus, is working as described. Except for messages are not loaded from errore.msg file initially. The location of errore.msg may vary from platform to platform, depending on location of FPC. But IDE's compiler messages can be configured to load the messages file by default, from a specified location. On Sun, Jan 24, 2010 at 4:47 AM, Marcelo B de Paula wrote: > Needed to change CompilerOptions.pp to load 'E' and 'F' types. It's not necessary to load E/F it should NOT be possible to "switch them off", as you say it yourself: > - The Project Options->Compiler Options->Messages should be tunned to not > present 'E' and 'F' types. The only tweak required here was to load translated "error", "fatal error" strings, so the OutputFilter could detect the type of the error and shown the proper Icon. It has been implemented a few months ago. thanks, dmitry

Reply by email

Marcelo B de Paula
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.

Yes, i think that this modification can be tagged to a new release of compiler and ide.

About translate messages working correctly on prior versions, i cannot confirm.
If i change compiler messages by loading another errorxx.msg in IDE or use a different errorxx.msg
to compile the compiler itself, the first thing i?ve noticed is that QuickFixItems stop working,
and message icons on message view form do not show correctly.

That?s because Quickfixitems and MessageView are comparing const strings in english only.

Excerpts:

  Result:=(Line.Partsnil)
          and (System.Pos(') Fatal: Can''t find unit ',Line.Msg)>0);

if REMatches(Msg.Msg,'Can''t find unit ([a-z_0-9]+) used by ([a-z_0-9]+)','I') then begin

------

const
  cHint         = 'Hint: User defined:';
  cNote         = 'Note: User defined:';
  cWarning      = 'Warning: User defined:';
  clMsgHint     = clBlue;
  clMsgNote     = clGreen;
  clMsgWarning  = clRed;
  cLeftSpacer   = 0;
...
  if not (cdsSelected in State)
  then begin
    TheText := Node.Text;
    if Pos(cNote, TheText) > 0 then
      ChangeFontColor(clMsgNote)
    else if Pos(cHint, TheText) > 0 then
      ChangeFontColor(clMsgHint)
    else if Pos(cWarning, TheText) > 0 then
      ChangeFontColor(clMsgWarning);
  end;

So, after changing TOutputFilter, there are much to do before using a custom language correctly.

Regards,
Marcelo

Reply by email

dmitry boyarintsev
to Marcelo B de Paula
Marcelo B de Paula wrote 5 lines
If i change compiler messages by loading another errorxx.msg in IDE or use a different errorxx.msg to compile the compiler itself, the first thing i?ve noticed is that QuickFixItems stop working, and message icons on message view form do not show correctly.

What Lazarus version are you using? Could you try svn version?

There has been a bug report about it. The reporter considers the bug fixed: http://bugs.freepascal.org/view.php?id=14775

thanks,
dmitry

Reply by email

Marcelo B de Paula
Show quoted text 7 lines
What Lazarus version are you using? Could you try svn version? There has been a bug report about it. The reporter considers the bug fixed: http://bugs.freepascal.org/view.php?id=14775 thanks, dmitry

Hello again dmitry,

Tested with svn version 23.543.
Sorry! The icons appear correctly. I can confirm it.

But QuickFix, as i explained earlier, continue with problem. A simple test with an undeclared
identifier didn?t fired the default quickfix to "Error: Identifier not found". It only works with english language.

Regards,
Marcelo.

Reply by email

dmitry boyarintsev
to Marcelo B de Paula

Indeed, quick fixes have hardcoded English messages.

It's possible to use translated messages, with out using message numbers, but it's much harder job than using -vq switch directly.

You're free to provide the patch for fixing the problem (and using -vq switch). But you should make the patch against svn version, rather than 0.9.28-x (or any earlier)
If you don't want to spend more time on this, or find it hard to do it by yourself. You can ask for help and/or fill the bug report at bugs.freepascal.org.

thanks,
dmitry

Reply by email

Marcelo B de Paula
Show quoted text 8 lines
Indeed, quick fixes have hardcoded English messages. It's possible to use translated messages, with out using message numbers, but it's much harder job than using -vq switch directly. You're free to provide the patch for fixing the problem (and using -vq switch). But you should make the patch against svn version, rather than 0.9.28-x (or any earlier)

My concern is that the code i have (TOutputFilter) is still experimental. I could not test it against other plataforms. So it will need someone else to do it.

Before we could use the message numbers (-vq), more code has to be reviewed like TIDEMessageLine, QuickFixes, BuildLazDialog... where message can affect the code behavior.

What i?m suggesting now is if someone can test it with other plataform, and give us an opinion. Of course that this test must be done with current svn and, following pre-requisites like including -vq in compiler.pp, loading errore.msg, and modifying the compileroptions to read the types 'E' and 'F'.

If you don't want to spend more time on this, or find it hard to do it by yourself. You can ask for help and/or fill the bug report at bugs.freepascal.org.

Help are always welcomed! :)

If you've a patch ready please send it to bugs.freepascal.org as well, creating the issue.

I can provide the necessary patch to test. I just didn?t uploaded it yet because i don?t know if mailing list is the right place. And considering it is experimental, i don?t think a good idea to upload to the bugtracker.

Regards,

Marcelo.

Reply by email

Graeme Geldenhuys
to Marcelo B de Paula: I?m aware on how to create a patch. This isn?t the case. The code needs some review and…
Marcelo B de Paula wrote
review and planning before merging it to trunk. I gave you the full source code. What more do you want?

I think what he meant is that it is easier to review changes when you only need to look at a patch file. The reviewer now needs to use a diff tool, or use the diff tool to create a patch, then review the changes.

Viewing only the changes (a patch file) is easier (less effort).

Regards,
- Graeme -

fpGUI Toolkit - a cross-platform GUI toolkit using Free Pascal http://opensoft.homeip.net/fpgui/

Reply by email

Marcelo B de Paula

I uploaded the code i have (TOutputFilter) to bugtracker, #15584.

Developers that wants to use or modify it, feel free to do it.

What i could do to help, i?ve done. Unfortunatly i have no free time at moment to conclude it. But still have some ideas if anyone is interested.

Any question about this code, feel free to ask.

Regards,

Marcelo.

Reply by email

Marcelo B de Paula
Using stand-alone files might be trouble some. It's better to report new features as patches Please see, http://wiki.freepascal.org/Creating_A_Patch

I?m aware on how to create a patch. This isn?t the case. The code needs some review and planning before merging it to trunk.
I gave you the full source code. What more do you want?

Marcelo.

Reply by email

dmitry boyarintsev
to Graeme Geldenhuys: I think what he meant is that it is easier to review changes when you only need to look…

Hello Marcelo,

I've recently been told about developing of a new fpc feature. The feature would allow user to override a default message type (any hint, note or warning) and treat it it as a error.

So determining a message type by its number would provide a wrong result (at least icon of the message would be incorrect). But of course, this feature is not yet implemented in FPC.

thanks,
dmitry

Reply by email

Marcelo B de Paula
Show quoted text 12 lines
Hello Marcelo, I've recently been told about developing of a new fpc feature. The feature would allow user to override a default message type (any hint, note or warning) and treat it it as a error. So determining a message type by its number would provide a wrong result (at least icon of the message would be incorrect). But of course, this feature is not yet implemented in FPC. thanks, dmitry

Ok!!

I think its better someone edit the wiki information: http://wiki.lazarus.freepascal.org/IDE_Development#Translated_compiler_messages

I really dream the day that i could use a 100% translated IDE/Compiler.

If you don?t mind, please discard bug #15584

Thanks,
Marcelo.

Reply by email