Recent

Author Topic: i18n problem  (Read 243 times)

nagylzs

  • New Member
  • *
  • Posts: 20
i18n problem
« on: November 17, 2019, 08:56:42 am »
I just enable i18n for a very simple project. Creation of po files when saving lfm box is checked in the project options, but properties of my forms are not saved into po files. For example, I have a TListBox with static Items - they do not appear in the po file. I have also tried to change the items and save the form, but it does not help. Also tried to clean + build the project, but that does not help either. The unit is added to the project.

This question is similar to https://forum.lazarus.freepascal.org/index.php?topic=33576.0 but I could not find any solution from that thread.

Thaddy

  • Hero Member
  • *****
  • Posts: 9309
Re: i18n problem
« Reply #1 on: November 17, 2019, 09:35:45 am »
You need to bring those static items outside of the Tlistbox. The listbox can only store them by the component streaming mechanism, they will never show up in the po files, so you have to declare the outside of the listbox. Those strings will end up in the po files and you can add them back to the listbox in code..
also related to equus asinus.

nagylzs

  • New Member
  • *
  • Posts: 20
Re: i18n problem
« Reply #2 on: November 17, 2019, 12:28:47 pm »
Is there a way to connect component streaming with i18n? The biggest problem is that in a GUI application, there are thousands of properties that could be visually designed and translated: TLabel.Caption TForm.Caption, button captions, grid column titles etc. It is very inefficient to manually write i18n code for for visually designed forms.

I could myself write program code to traverse the component tree, find these translatable properties and save/load their values at runtime. But it would be much more efficient to build this function into component streaming and the visual designer itself.

I was a Delphi programmmer about 10-15 years ago, and I can remember that Delphi already had this functionality built-in: not only manually declared resource strings, but also published string and stringlist properties were extracted automatically and they could be translated. I don't remember the exact method, but I believe the translations went into separate DLL files. I'm not saying that gettext is wrong. I'm just saying that if it was working in Delphi 5, then it should also probably work in Lazarus.

nagylzs

  • New Member
  • *
  • Posts: 20
Re: i18n problem
« Reply #3 on: November 17, 2019, 12:31:07 pm »
I guess it wouldn't be hard to do either: extract string/StringList properties into po files as part of the build process, and call gettext() on all string/stringlist property values when loading them at runtime.

wp

  • Hero Member
  • *****
  • Posts: 6502
Re: i18n problem
« Reply #4 on: November 17, 2019, 12:41:39 pm »
Do you have LCLTranslator (or DefaultTranslator) in your uses clause? It does exactly that: translate standard string properties and strings in collections. However, it does not translate strings stored in TStrings descendants (e.g. Listbox.Items)... You should ask on the Lazarus mailing list why this is so and whether it could be changed (the maintainer of the translation system only rarely is in the forum).

To learn about LCLTranslator you should have a look at the demo project in folder "examples/translation" of you Lazarus installation.
Lazarus trunk / fpc 3.0.4 / all 32-bit on Win-10

nagylzs

  • New Member
  • *
  • Posts: 20
Re: i18n problem
« Reply #5 on: November 17, 2019, 12:49:31 pm »
Yes, I have DefaultTranslator listed. By as far as I understand, that will only translate strings that are part of the standard library. E.g. it will not translate simple string properties (like TLabel.Caption) unless they are part of the standard library. (I may be wrong on this?)

I'm going to write to Lazarus mailing list later, thanks.

wp

  • Hero Member
  • *****
  • Posts: 6502
Re: i18n problem
« Reply #6 on: November 17, 2019, 01:02:19 pm »
I may be wrong on this?
Yes, you are wrong. Did you look at the demo? It shows that all component Captions are included in the po files; the resource strings unit contains only some dedicated strings used by the app.

The problem with LCLTranslator/DefaultTranslator is that multiple copies of the Captions of different components with the same text appear in the po files, and you have to exclude the duplicates from translation, otherwise your translators will have a hard work. (But maybe I am not up-to-date on this point, Maxim recently put a lot of work into the translation system).
Lazarus trunk / fpc 3.0.4 / all 32-bit on Win-10