Hallo Fred van Stappen, vous ecrit au Mon, 14 Feb 2022 18:35:11 +0000:
> It will be great to have a "automatic" caption-to-constant converter. > Maybe you could take a look > at /mseide-msegui/tools/i18n/resourceparser.pas I'll give it a look for sure. > Two years ago I jumped into the mse-i18n project. > Like you explained it works like a "kaliédoscope" producing a > library for each language (or face). It is very good but, imho, has > too much unneeded features if only internationalization is the goal Well, may be you remember that I also took advantage of that implement, but I used it just for those "unneeded features", i.e. for its abilities to modify the _appearance_ of gui elements, as I had the need to support multiple screen resolutions for "my" project. Translation to other languages was not my prospect. > Also it uses the "mseconst_xy.pas" way and needs so to compile the > language unit to create the lang-library. And no po file link was > developed. It seems to me that it "slept away" silently, no longer maintained and not much in use anyway. It was the time just before Martin developed his "skin" functions (which I never yet came to use), and by now, its language abilities might be taken over by the .po/.mo approach. May be we can wish it R.I.P.? > But there are lot of interesting code for parsing resource. Yes, but I rather strive for a method that does NOT need to parse something yet another time - the approach should use the _internal_ data structures of the application as much as possible and need as little additional catering as feasible. Scanning the component tree should give much of that information and provide access to all visual elements needing translation (labels, buttons, lists...), and it might be possible to use fpc's (new?) .rsj resource files (or any resource string implementation) to reach the remaining textual elements. > At the moment, for a other project with lot of captions, I use > extended features of "potools" converter. This should be a built-in feature of the aforementioned scanner, using something like a "report generator" to name all the instances of text elements found. It could possibly be a "design time" functionality, providing a call to save all text elements of the layout to a file. But I'm not at all familiar with the workings of this family of functions. > It extracts, from a msegui form.mfm file, the caption of each > component of the form and shows in a memo the code of the enum and So it is a separate preprocessor stage producing another kind of (code) ressource that has to be incorporated into the application. I also considered such an approach at first, because it looks so obvious. But then I remebered that at first, Delphi, and later on (of course) Lazarus implemented a method to access all the gui components of an application via a built-in tree structure, and I looked for such a thing in mseide-msegui. And there _is_ such a construct, used, as it seems, mainly for "streaming" the gui elements to and from disk, not being used much otherwise. So, why not use it for some other purpose? I think, I'll keep trying to make use of it, just have to find a way to make it accessible without having to overturn the existing unit structure too heavily... Thank you for your consideration! -- (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
