Hallo Fred van Stappen,
vous ecrit au Mon, 11 Apr 2022 00:12:26 +0000:
> I have tested your last formscanner_experimental_2.zip project.
>
> Wow, kind of magical that it can scan and translate the captions of
> all the forms **without** the need to assign the new caption for each
> widget, like I did in ideU.
Yes, that was the intention - these items are accessible for any
program functions, so they can be found and modified at runtime by an
appropriate procedure.
The task is twopartite:
first, all the relevant items have to be found and registered, in which
process they have to be classified as to how they can be modified, and
secondly, when the real translation, i.e. modification, occurs, the
information gained from the first part has to be used to correctly
change the values.
> In the test all the froms are translated correctly there is only the
> main menu where the items are not translated (maybe I missed
> something).
For me, using the ideU_de.mo file I included in the archive, the main
menu gets translated also. It probabely does not so, and other items
will be missed as well, for any other language, as I didn't produce a
translation for any other language (which I wouldn't know anyway).
Sure, some items may be missed still, and any caption or hint or
whatever that has been modified in its original version (probabely)
will be left unchanged also.
> Maybe (this is a litle detail), instead of
> PROCEDURE ShowFormItems (CONST FormName: string = '') that uses
> "writeln()", transform it into
> FUNCTION ShowFormItems (CONST FormName: string = ''): string;
> And replace all the "writeln('xyz')" by "result := result + 'xyz' +
> #10#13"". This to be compatible for Windows GUI applications.
> But this is maybe for the end, when all is working perfectly.
This procedure is still only a crude attempt to produce some viable
and possibly useful output. Of course it can be adapted to the needs
of other program parts that want to use it. But instead of a simple
string, I'd plea for a string list as the result. This can easily be
transformed into a string, in fact, it can do that "itself", but its
otherwise a lot more flexible to process. The separator lines (dashes)
shouldn't be there as well, they were just visual clues for me to find
the right part of the output to see if it looked right.
> Anyway your formscanner is very impressive.
Well, it's still quite limited, as it can only provide modifications
for exactly specified strings. No variation may be present, not even a
change in case or even whitespace. And it's not even simple to take
care of these details, as there might be cases where this can be
decisive to the meaning of the text (chinese perhaps?).
I can think of two possible enhancements, though.
For one, one could provide automatic removal of "&" characters for
items where there is none, although a translation containing one is
available. Then the original item would be replaced with the
translation stripped of the "&". This should be "quite easy", and it
would obviate the need to provide separate translations for all items
that need no "&" marker.
For another, one could provide a method to insert a variable part into
a specially marked position in the translation, equivalent to such a
marking in the original text. This could help where a translation
requires shifting part of the text from before to after the variable
part, thus relieving the user from ascertaining the correctness and,
even more important, the freeness from collisions of every part with
other texts.
To achieve this, a new function for variable insertion would have to
be created, and this would have to be used for the original text also.
> I will be out of computer for some time but will come back asap.
No problem, I'm quite busy at other problems anyway, although I was
just able to remove a road block that kept me searching quite some
time. Did you suspect that the simple - Turbo Pascal - sequence
"assign (<texfile>, ''); rewrite (<textfile>);" could render your big
application unusable? Yes, it can - producing an unspecific "access
violation" under not yet really clear circumstances...
It's even mentioned in the fpc documentation!
> Have perfect days.
Thanks, same to you, and "see you later".
vous ecrit au Mon, 11 Apr 2022 01:39:18 +0000:
> Forget my previous proposition about replace procedure into function,
> there is the "verbose" variable to set to "false" to disable the
> "writeln()".
I'm afraid you mixed that up a bit - this variable turns off the ERROR
output by writeln and instead produces either a string list containing
all error messages or calls a call-back procedure that gets an error
message passed for immedaite handling. It does NOT pertain to the
"ShowFormItems" procedure.
> I have a "Exception" error at running the ideU-formscanner project
> with this:
>
> "List index(11) out of bounds"
That's strange - it doesn't occur to me here. Did you modify some
caption, hint, menu item or such lately? This might be able to cause
that error, especially if something was removed or added.
> But clicking on OK the application starts, only the main menu items
> are not translated, all the captions of all the forms are translated
> (but some hints are not translated).
This could be a consequence of additions that are not yet contained
in the set of translatable items. But certainly, this shouldn't produce
a "List index(<>) out of bounds" exception, at least not for more than
the missing item(s). I will look at that problem when I can do so again.
Thank you for the report!
--
(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