Hallo Fred van Stappen,
vous ecrit au Sun, 6 Mar 2022 00:00:23 +0000:
> Yes, I know it is very boring and each time that a bug appears, it is
> very sad because it kills the current version. I really hope that
> last commit has fixed everything but I cannot guaranty it.
There can't be a guarantee, for sure, and that's often the reason that
such a project keeps one "long time proven stable" public release
version, and another constantly updated internal development version.
Alright, the work on localization is part of the development version,
not to the release one.
> Also take in account that fpc, mainly since fpc 3.0.0. does lot of
> change and added lot incompatibilties that must be fixed. I did try
Yes, I realize that there is a lot of work to do following external
development this project is depedent on. I'm not envious.
> Do you follow Lazarus forum?
No, although I have a version installed, I've no real application for
it, not right now, at least.
> If yes, you will see that Lazarus is stiked with fpc 3.0.0, using fpc
^^^^^^ stuck?
> 3.2.2 added lot of problems for Lazarus. And compiling Lazarus with
> fpc 3.3.1 is not yet possible (or higly instable).
>
> MSEide on his part is fully compatible (with fpc 3.3.1. trunk of
> today).
Yes, you did very good - and much - work to keep pace with fpc's
development, which makes mseide-msegui a forerunner in the field -
it really deserved being a lot more recognized.
...
> msegui 5.6.6 was added our "dynpo" dynamic loading of po-mo files
> (that should be completely ok in last commit 5.6.7).
That's good to know, but here I am the one causing some upheaval,
because I found a real problem with the po4stock unit:
Internally, it uses the "mseconsts" unit, which defines a few "generic"
arrays of strings, among them the array "en_langnamestext", containing
6 entries. Now, as that is a _constant_ array, it cannot accept more
entries, but if an application, e.g. like your ideU, wants to provide
more languages, there is a conflict between this fixed internal array
and one possibly provided by the application. This caused some problems
when I tried to integrate it into your ideU code - it kept causing
errors and crashes, and even the debugger got confused often. And
me too - i wondered why the (appliction provided) array wouldn't get
sized correctly, and although the size was given as "6", it was shown
as having the value "nil". Until I realized the unit clash, and now
I'm wondering how this dilemma could be solved. I see two ways, right
now:
For one, it would be possible to introduce (infiltrate) an overriding
unit into po4stock by means of a macro, which would require the whole
application to be compiled with macros enabled (switch "-Sm"), or
for another, if it was possible to get rid of the "en_langnamestext"
array in "mseconsts.pas" or - using a newer feature of fpc (as of
version 3.0, they say in their documentation) to change this to an
_initialized_ dynamic array, making it expandable to any number of
entries needed.
This would make "po4stock.pas" completely independent of any
application, and thus perhaps electable as a candidate for inclusion
into the library. And, it will make handling of application dependent
translation strings much easier than right now, only requiring to
provide a set of definitions referencing the application provided
array of translatable items. (You might have noticed this in the
latest revision of the modifications for your ideU in "ideU_mo.zip".)
> Now when to decide to release msegui 5.6.8...
> I wait for your green light, it seems that for Code DZ it is ok.
Well, "don't hold your breath", as they say, just proceed.
But I do have a wish:
I took some time to create a couple of compatibility modifications to
"msestockobjects.pas" to allow getting rid of most of the
{$ifdef mse_dynpo} conditionals found in many of the library files.
I even did take the time to modify all these files, and did some
compilation work with them (mainly, your ideU), which seemed to produce
correct.code, as far as I could find out.
I would be really very pleased, if you could consider this stuff and
perhaps - if no errors should show up - even include it in the library.
Previously, I uploaded the modifications (file "msegui-lib_dynpo.zip"),
admittedly in a version that's not quite current any more.
If you think it was useful to include, I'll repeat the process and will
upload a revised version of all the pertaining files.
Thank you very much for your kind consideration.
...
> Hum, you see, it is the same for me, without git or svn, it is
> impossible for me to know if you did a new zip file (I dont have
Yes, I do realize that. I would be glad it it was possible to provide
the files by ftp, but I might just as well upload a html page displaying
a directory listing for you. I'll give you notice when I did, then you
can always see the file's data there.
...
Vous ecrit au Sun, 6 Mar 2022 16:53:43 +0000:
> >BTW, did you realize the modified version of POtoMO, and did you test
> > whether this could resolve your translation problems?
>
> OK, re-downloaded http://schs.de/download/mse/POtoMO.zip.
> Compilation: out-of-the-box.
> Producing MO file from updated PO files: PERFECT!
Fine, good to know that it works for you also.
> Also very nice to show the "double" ID and wait to produce the MO
> file until all is clean in the PO file, congrats.
Well - there are probabely still many causes for failure, the syntax
isn't checked thoroughly, and only the most obvious "inadequacies" can
be recognized. For source (.po) files that are not too much off it
should be viable though. But be warned: there's exactly NO provision
for multibyte unicode character sets, so chinese or similar character
sets might very well go astray if used. This will have to wait until
mseide-msegui is capable of correct display of such characters,
probabely.
> But all this obliged, once again, to do a new commit for
> mseide-msegui with your updated
> project /mseide-msegui/tools/POtools/POtoMO/. It was done just now.
Do you think that a full commit is warranted in this case? Or, asked
differently, isn't it possible to just re-commit only a pertinent part
of a project? I think I saw a possibility to create something like
sub-projects to a main one hosted on Git-Hub, and the POtoMO stuff
should be a prime candidate for this, as it is not really required for
the main project.
> So if you have already downloaded mseide-msegui, I apologize but you
> will need to do it once again:
No problem - if just this part has changed, I wouldn't even need to
(request my machine to) download it again.
> Anyway, many WoW for your all your MO code, it works out-of-the-box,
> fast and nice.
> Sure it adds a big plus for msegui.
Thank you for your compliment. I'm glad having been able to contribute
to this great development.
(And, BTW, I'm already about to find ways to automatically gather all
the relevant strings from captions, hints and the like of a project
without the need to build a special unit containing all of them -
they're there already, in the object definitions, so why not use them?)
Best wishes for all your work!
--
(Weitergabe von Adressdaten, Telefonnummern u.ä. ohne Zustimmung
nicht gestattet, ebenso Zusendung von Werbung oder ähnlichem)
-----------------------------------------------------------
Mit freundlichen Grüßen, S. Schicktanz
-----------------------------------------------------------
_______________________________________________
mseide-msegui-talk mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/mseide-msegui-talk
