ESS-Model again

[JuhaManninen]

I have improved the traditional GUI windows by setting anchors and default font etc.
I also tried to add i18n support but I cannot see translated texts. See my post in the "Application Translations" thread.
I am a newbie in i18n support issues.

The improvements from dicepd sound impressive although I have not studied the code deeply. You clearly understand the code much better than I did when I tried to port it.
Q: should dev branch perhaps be merged to master? Now all kinds of development happen in dev and master is not used.

I realized the freezing with GTK2 when File menu is opened, is this one:
 http://bugs.freepascal.org/view.php?id=31138
It is a regression. If somebody found the guilty revision, I would be happy.
I will travel soon and may have a pause ...

[dicepd]

I got a Finnish version working with the modified files I have just commited.

You have to symlink the locale directory under the debug to make it work in IDE.

Merged Dev into Master.

Fixed missing files for Finnish language.

[dicepd]

i18n work.

Have done first pass through the code for strings that are displayed and replaced them with resource strings in uConst. po files updated.

Diagram strings not done yet.

This pass will only be valid for left to right languages, I will leave bidir problems to someone who can understand and TEST.

Next up check controls.

Anyone got any pointers to  i18n for rtti controls, for name substition?

Peter

[JuhaManninen]

I got a Finnish version working with the modified files I have just commited.
You have to symlink the locale directory under the debug to make it work in IDE.

Thanks, the symlink helped. Other choice would be to generate the executable into the project dir.
Somehow the project icon ('MAINICON') got lost. It came from a resource, it was not defined in project options. Maybe it should be.(?)
This now affects also the About dialog.

[dicepd]

Thanks, the symlink helped. Other choice would be to generate the executable into the project dir.
Somehow the project icon ('MAINICON') got lost. It came from a resource, it was not defined in project options. Maybe it should be.(?)
This now affects also the About dialog.

Symlink is probably best as we just have to git ignore the lib dir and not a lot of other stuff.

Will check on the resource but I seem to remember checking that in.

[dicepd]

Icon sorted. Let Lazarus do it's thing with the resouce file, it wanted a renamed copy of the icon in root so I checked that in.

I'll leave you to sort out the rest of the controls re. i18n as I am starting on an draggable orthagonal connector with all the trimmings.

[minesadorada]

Re: i8n

Here are English and Spanish .po files for testing (Spanish is machine translation, with a little help)

Interesting app, but not sure what it's for..

BTW the Project options are missing:
Icon (which crashes the About dialog)
Target Filename(=LazModel) which prevents i8n translation (maybe then no need for symlink if a relative path is also specified, and /locale is copied over?*)

*This is why (for distribution) I bundle the po files as a resource then unpack them (if not already present) to a /locale folder in form initialization - that way, they are always available even if the executable is moved.

No need for DefaultTranslator in unit uMainModule or anywhere else
Option 1: In uMainForm replace Uses: DefaultTranslator -> LCLTranslator
In Form.Create:

Code: Pascal  [Select][+][-]

1. procedure TMainForm.FormCreate(Sender: TObject);
2. begin
3.   Height := Max( Round(Screen.Height * 0.75), 480 );
4.   Width := Max( Round(Screen.Width * 0.75) , 640 );
5.   {$IFDEF DEBUG}
6.   ClassTreeEditForm := TClassTreeEditForm.Create(Self);
7.   {$ENDIF DEBUG}
8.   SetDefaultLang('fi','locale',true); //  <<< testing - can now be 'en' and 'es' etc.
9.   MainModule := TMainModule.Create(Nil);
10. end;
11.  

..or better still Option 2: you can put it in the LPR file

Code: Pascal  [Select][+][-]

1. Uses ...long list..., LCLTranslate;
2.  
3.   Application.Initialize;
4.   Application.Title := 'Laz-Model';
5.   SetDefaultLang('fi','locale',true); //  <<< testing - can now be 'en' and 'es' etc
6.   Application.CreateForm(TMainForm, MainForm);
7.   Application.Run;
8.  

As I remember DefaultTranslator just calls LCLTranslator.SetDefaultLang('','',true) and LCLTranslator looks for 'locale', 'language' etc as folders that contain .po files, and uses the system settings to set the language prefix.

Anyway, i8n seems to work okay in Windows 10, but the code needs more strings to be made into resourcestrings throughout the project

i.e. (in uMainModule)

Code: Pascal  [Select][+][-]

1.     ShowMessage(
2.      'Syntax: '#9 + ChangeFileExt(ExtractFileName(Application.ExeName),'') + ' [options] [@list] [files...]'#13#10#13#10 +
3.      'Valid options are:'#13#10#13#10+
4.      '    -d[path]'#9'Generate documentation to the path specified'#13#10 +
5.      '    -a[+/-]'#9'Show associations on generated diagrams on/off'#13#10 +
6.      '    -v[0-3]'#9'Visibilty filter for generated diagrams'#13#10 +
7.      '    -x[file]'#9'Export model to xmi file')
8.  

which needs to use Format('',[]) (or ShowMessageFmt) and the const LineEnding (as a parameter) rather than #13#10.  The (format %s,%d etc)-type  strings are better for resourcestrings/translation to work with.  You can also use Highlight String->Right-click->Refactoring->Make resourcestring in the IDE editor pane to make it easy.

something like:

Code: Pascal  [Select][+][-]

1. Var sInShowHelp:String
2. begin
3. ....
4.      sInShowHelp:='Syntax: %s%s [options] [@list] [files...]%s%s' +
5.      'Valid options are:%s%s' +
6.      '%s-d[path]%sGenerate documentation to the path specified%s' +
7.      '%s-a[+/-]%sShow associations on generated diagrams on/off%s' +
8.      '%s-v[0-3]%sVisibilty filter for generated diagrams%s' +
9.      '%s-x[file]%sExport model to xmi file';
10.      ShowMessageFmt(sInShowHelp,
11.      ['#9',ChangeFileExt(ExtractFileName(Application.ExeName),''),LineEnding,LineEnding,
12.      LineEnding,LineEnding,
13.      '#9','#9',LineEnding,
14.      '#9','#9',LineEnding,
15.      '#9','#9',LineEnding,
16.      '#9','#9'
17.      ]);
18. ...
19. end;

..where the string variable sInShowHelp text can become a valid resourcestring that is more easily translateable in poedit

I really like the i8n facilities in Lazarus
(all applies to trunk BTW)

[dicepd]

@minesadorada

Thanks for the files I have checked them in. Re. command line strings, most of this functionality is broken and is bound to get greatly altered so it was not resource stringed (no point in making work that may get thrown away).

But thanks for the pointers on good handling of such strings. It is now nicely filed away here on the board for future reference.

 

[minesadorada]

@minesadorada

Thanks for the files I have checked them in. Re. command line strings, most of this functionality is broken and is bound to get greatly altered so it was not resource stringed (no point in making work that may get thrown away).

But thanks for the pointers on good handling of such strings. It is now nicely filed away here on the board for future reference.

 

Yes, I figured ChangeFileExt(ExtractFileName(Application.ExeName),'') wouldn't play too well in Windows..

[dicepd]

Though Format for multiple variable words is generally not a good idea. As the following very silly example shows

Format('The %s is %s', ['cat', 'sleeping']);

When in other languages the grammar may be 'Sleeping is the cat' which then becomes untranslatable, or sounds like chinese documentation;)
 

[minesadorada]

The idea is leave out untranslatable items from the string, such as control characters, variables and functions - so that everything in the resourcestring is translatable.  The only stuff in the parameters of Format should be untranslatable - that's why the 'LineEndings' go in there for instance.

Also good i8n design is to keep strings understandable as translations, and avoid fragments.
Here's an example of how not to do it (from my own code):

Code: Pascal  [Select][+][-]

1. resourcestrings
2. rs_By = 'By';
3. rs_For = 'For';
4.  

Where it is used:

Code: Pascal  [Select][+][-]

1. sz:='Some words :';
2. sz += rs_By + ': ' + fAuthorname + LineEnding;
3. sz += rs_For + ': ' + fOsString + LineEnding;
4.  

Building up a string over several statements is not i8n-friendly. (for instance 'For' can be translated to Spanish as 'por' or 'para' depending on context, which is not there in rs_For)

...Where it should be one statement:

Code: Pascal  [Select][+][-]

1. sz:=Format(rsBetter,[fAuthorname ,LineEnding,fOsString ,LineEnding]);

Code: Pascal  [Select][+][-]

1. resourcestrings
2. rsBetter='Some words by %s%sfor %s%s'

..which is translatable as a single resourcestring (only the words 'Some words by' and 'for' need translating, and there is context - any translator will safely ignore all the %s tokens as irrelevant)

The disadvantage I suppose, is that the source code is less readable when it comes to 'maintenance time'.

The other important thing in i8n design is to be sure the translations will look okay in the GUI (i.e. labels etc are big enough to cope with different word lengths)

[dicepd]

I was not saying your example for the command line was in any way wrong as that is very structured text.

However, even in your rsBetter example you still assume the order of fAuthorname and fOsString in the string. Even though that particlar example it is perfectly valid and works well.

i18n really needs a Format with unix style %1 %2 %3 for parameters so the translator can order them in any way he/she sees fit.

[JuhaManninen]

No need for DefaultTranslator in unit uMainModule or anywhere else

Actually it is needed in every GUI form when adding a quick and automatic localization support. That's what I did.
Then all GUI strings will appear automatically in the .po file, no resourcestrings are needed.
I don't know how it works. It looks like magic! LCLTranslator even has no initialization section. Maybe I will learn it one day...
This automatic localization has one problem. The actions connected to menu items are translated twice, once for the action itself and once for menu caption. This could be improved by using explicit resourcestrings.

I will have a pause with this app. I invite anybody to improve the localization and other parts.
Just fork the GitHub repo and make a pull request.
dicepd has kindly given me write access to the main repo, I guess both of us can merge the forks.

[dicepd]

Latest Change

Quite a big one this. I have implemented an Orthagonal PathLayout which makes for better looking class diagrams.

PathLayout is now a substitutable concept within a Layout (although no GUI mechanism to do so as yet). I have skeletons for Vector PathLayouts ( I have to port the original code into this) to be used in dependency diagrams or where ever else it makes sense. Also a RoundedCorner PathLayout. Further Layouts and PathLayouts can be added to cope with differing future diagrams (SwimLaneLayout for example for call trees)

This will enable differing Diagrams to use the same base panel and just request the appropriate layout on creation (not implemented yet).

Path Decorations have been started but the current arrow head is a kludge until I can get styles which are based on associations.

It is my intention to replace members as direct link to datatype, as implemented currently, with associations. Associations introduce cardinality and  template realisation amongst other things.

Some of the new code uses generics, if you are running an FPC < 3.0.1 then an internal error may occur in uLayoutConnector. Workaround is to delete all items in the build directory.

Peter

[dicepd]

Latest change.

Rounded paths and Direct paths now working and selectable from toolbar.

Uses current ini file to persist pathstyle for each drawing.

i18n  for Toolbar combos contents.

Peter