* * *

Author Topic: Strange behaviour collecting strings from a form  (Read 314 times)


  • Jr. Member
  • **
  • Posts: 71
  • Very experienced in being a beginner...
Strange behaviour collecting strings from a form
« on: April 01, 2017, 11:43:57 pm »
I have a project which I've planned on translating from the beginning, but I came on several problems. This is an example of the PO file created by Lazarus:

Code: [Select]
#: tfprocessing.taskrefresh.caption
msgctxt "tfprocessing.taskrefresh.caption"
msgid "1. Refresh from folders"
msgstr ""

#: tfstart.taskloadhashes.caption
msgid "2. Load hashes from DB"
msgstr ""

#: tfstart.taskpending.caption
msgid "3. Calculate pending hashes"
msgstr ""

#: tfstart.taskrefresh.caption
msgid "1. Refresh from folders"
msgstr ""

As you can see, some strings have msgctxt set (same as the #: above them), while others not; of the ones with it, some have it in lowercase and others in uppercase. The msgctxt is set only for strings with the same content. Note that the first string is from a different form than the last.

I discovered this because for some reason the first PO generated had one string with a lowercase msgctxt content. The translated string (recognized and translated by POEdit) did not load in the project and showed untranslated, until I manually transformed its msgctxt content to uppercase. After some attempts at regenerating the PO file (which requires restarting Lazarus, since it keeps some stuff in memory) I got another combination of no msgctxt, and lowercase and uppercase msgctxt content. This time other strings had lowercase msgctxt content. They wouldn't be translated when my project shows them.

Note: strings without msgctxt are translated correctly. So I don't know what's the point of creating msgctxt apparently randomly in upper and lower case variants (the origins are all in uppercase in the form LRT files).

Has anyone encountered a problem like this? Is it fixable? Should I file a bug?

The second problem is more subtle. One label in one form has two lines, separated by a newline. Inside the LFM of the form, it looks like:
Code: [Select]
Caption = Line1.'#13#10'Line2.'
Inside the LRT file for the form, the string looks like:
Code: [Select]

It's split in two lines. Which in turn creates two strings in the PO file. The first one has the comment for its source, the second one has no comment. Irrelevant, since none of them is the original string, thus it's not translated. I'm guessing PO/MO files don't handle new lines like the LFM/LRT files. So how would I add a new line in a label in a way compatible with the PO exporting? Or should I use some custom code?

In any case this causes trouble when working with a PO file made by Lazarus, so I think it grants a bug report, what do you think?

The third error is a consequence of the second error. When I recreate the PO file from scratch and load it in POEdit, it warns me that there were duplicate elements. Not duplicate strings (msgid), but duplicate elements. This happens only when a label has a new line, causing the problem already described, but also it creates the string twice in the PO file. This has caused many headaches for me until I discovered this was the source of many other errors with the PO file...

Thanks for your attention on this subject.
Lazarus 1.6.4 + FPC 3.0.2 64bits under Windows 7 64bits
Only as a hobby nowadays
Current proyect release: TBA



Get Lazarus at SourceForge.net. Fast, secure and Free Open Source software downloads Open Hub project report for Lazarus