Hallo Fred van Stappen, vous ecrit au Sat, 5 Feb 2022 18:38:45 +0000:
> By the way, about internatization of ideU, (nearly) all should be > translated now. So the po files ( +- 1000 msgid's ! ) are ready to be That's quite some stuff indeed. > transformed into MO files. For the greman translation, I followed > your modifs but since your post there was lot of new msgid added. And > maybe some are not well translated (Google Translate did the job). Might make for some laughter... These machines usually are very much commercially prone, not really suited for technical stuff. > (Last commit:) > https://github.com/fredvs/ideU/archive/refs/heads/main.zip I'll get it "immediately"... You'll get the results, but only when I had the time. vous ecrit au Sat, 5 Feb 2022 19:52:27 +0000: > About PO2MO program first touch: > > Out-of-the-box, works like charm, no error, no cry, a beatiful MO > file is created with: Glad to here it works for you too. There's still a lot to be optimized, e.g. adaption to machines of different byte order (the fpc TMOfile does regard this), and much towards error handling. > > po2mo ideu_fr.po > > But the size of the mo file is bigger than the po file: Yes, that's the case with the "msgfmt" converted files too. It's caused by the _added_ hash table, that more than compensates for the line feeds and key words in the .po file. BTW, I found some hints as where to put translation files for the "gettext" system, which is the "standard" the .po and .mo translation files adhere to. It says this (sorry, rather long text): ------------------------------------------ 11.2.3 Locating Message Catalog Files ------------------------------------- Because many different languages for many different packages have to be stored we need some way to add these information to file message catalog files. The way usually used in Unix environments is have this encoding in the file name. This is also done here. The directory name given in 'bindtextdomain's second argument (or the default directory), followed by the name of the locale, the locale category, and the domain name are concatenated: DIR_NAME/LOCALE/LC_CATEGORY/DOMAIN_NAME.mo The default value for DIR_NAME is system specific. For the GNU library, and for packages adhering to its conventions, it's: /usr/local/share/locale LOCALE is the name of the locale category which is designated by 'LC_CATEGORY'. For 'gettext' and 'dgettext' this 'LC_CATEGORY' is always 'LC_MESSAGES'.(1) The name of the locale category is determined through 'setlocale (LC_CATEGORY, NULL)'. (2) When using the function 'dcgettext', you can specify the locale category through the third argument. ---------- Footnotes ---------- (1) Some system, e.g. mingw, don't have 'LC_MESSAGES'. Here we use a more or less arbitrary value for it, namely 1729, the smallest positive integer which can be represented in two different ways as the sum of two cubes. (2) When the system does not support 'setlocale' its behavior in setting the locale values is simulated by looking at the environment variables. ------------------------------------------ So this specifies only the position for _system_ use of such files, such as installed by a packetizing system, like Debian's "apt" or RedHat's "rpm". It does not specify anything for a user's locally installed programs. So I'd suggest to take the freedom to put the latter into a directory in the user's home directory, either, as I suggested before, directly, named "~/.<program name>" or under "~/.config", named after the program itself. Other configuration data might also go there, then. > About the speed of charging, I did not test because I dont not know > yet how to use mo files. With my laptop cpu i5 + 16 megas ram, > loading po file is nearly instantaneous for ideU ( +- 1000 msgid's). Concerning the use of .mo files, with my message from Tue, 1 Feb 2022 16:38:27 +0100, I uploaded two archive files, "msegui_dynpo-mod.zip" and "msegui-lib_dynpo.zip", into my web space. They contain a modified version of your "podemo" program using fpc's "TMOfile" object, the .mo files for localization, and a "slightly massaged" library for using msegui with "dynpo" support, respectively. These still are built upon the strategy of translation in advance, when all localized strings are replaced during program start-up, so there's no further translation to be done later. This requires the implementor to actively touch every single occurrence of every translatable text, which might cause a number of those to be overlooked and cause distractions. And aside from this, it requires rather much effort to implement all the assignments for all the different uses. I'd like to come up with a more general method to produce the translations, both for finding the pertinent occurrences for creation of a translation file (.po style, which you have provided already), and for actually performing the replacement of all the strings on program start-up, or maybe even only "per use" during runtime. Quite some digging and diving into code to arrive at a viable method will be neccessary yet. -- (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 mseide-msegui-talk@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mseide-msegui-talk
