Getting the error "Translation entries in the file are probably incorrect."

[CatalinFrancu]

Hi,

Thank you for poedit. I have been using it for years in two of my projects without any issues. However, I took a break for about a year and now I can no longer update from sources. I receive the error in the subject. I am including a minimal example.

• OS: Arch Linux, freshly updated, standard poedit package.
• poedit version 3.3.1
• I have cleared the translation memory (Stored translations: 0).
• I have deleted the config file and created a fresh one, see below.
• No custom extractors, only the GNU collection.

[cata@neil php-test]$ cat ~/.config/poedit/config 

```bash version=3.3.1 file1=/home/cata/Desktop/php-test/ro_RO.po file2= file3= file4= file5= file6= file7= file8= file9= display_lines=0 translator_name=Cătălin Frâncu translator_email=cata@francu.com compile_mo=1 show_summary=0 focus_to_text=0 enable_spellchecking=1 custom_font_list_use=0 custom_font_text_use=0 custom_font_list_name=Liberation Sans 10 custom_font_text_name=Liberation Sans 10 use_tm=1 merge_behavior=fuzzy_match keep_crlf=1 crlf_format=unix wrap_po_files=1 wrap_po_files_width=79 [Parsers] MigratedTo20=1 CustomExtractorsList= [TM] search_paths=/home/cata:/usr/share/locale:/usr/local/share/locale [windows] [windows/mainwin] w=1400 h=1860 maximized=0 ```

[cata@neil php-test]$ ls -la
total 16
drwxr-xr-x 3 cata cata 4096 Jun 22 17:47 .
drwxr-x--- 4 cata cata 4096 Jun 22 17:32 ..
drwxr-xr-x 2 cata cata 4096 Jun 22 17:45 lib
-rw-r--r-- 1 cata cata  418 Jun 22 17:46 ro_RO.po

[cata@neil php-test]$ ls -la lib/
total 12
drwxr-xr-x 2 cata cata 4096 Jun 22 17:45 .
drwxr-xr-x 3 cata cata 4096 Jun 22 17:47 ..
-rw-r--r-- 1 cata cata   42 Jun 22 17:44 a.php

[cata@neil php-test]$ cat lib/a.php 
<?php

print _('msg-hello-world') . "\n";

[cata@neil php-test]$ php lib/a.php 
msg-hello-world

[cata@neil php-test]$ cat ro_RO.po 
msgid ""
msgstr ""
"Project-Id-Version: \n"
"POT-Creation-Date: 2023-06-22 17:15+0300\n"
"PO-Revision-Date: 2023-06-22 17:46+0300\n"
"Last-Translator: Cătălin Frâncu <cata@francu.com>\n"
"Language-Team: \n"
"Language: ro_RO\n"
"MIME-Version: 1.0\n"
"Content-Type: text/plain; charset=UTF-8\n"
"Content-Transfer-Encoding: 8bit\n"
"X-Generator: Poedit 3.3.1\n"
"X-Poedit-Basepath: lib\n"
"X-Poedit-SearchPath-0: .\n"

[cata@neil php-test]$ poedit ro_RO.po 

Here, Poedit tells me there there are no translations (correct). The translation properties window correctly shows the base path /home/cata/Desktop/php-test/lib/. The only path is . and there are no excluded paths. Next, I hit Update from Code, as I have done for so many years, and Poedit says:

Thu 22 Jun 2023 18:05:57 EEST: Translation entries in the file are probably incorrect.
Thu 22 Jun 2023 18:05:57 EEST: Updating the file failed. Click on 'Details >>' for details.

Looks like the error is raised from edframe.cpp, after the checks for file existence and permissions pass.

Thanks for any thoughts!

[vslavik]

I am including a minimal example.

You're not. You dumped a wall of text that would take non-trivial effort to turn into something that can actually be tried in Poedit. Please do follow the instructions in SUPPORT.md. Namely, provide reproduction files and actually say what you think is wrong and why you think it's wrong.

[CatalinFrancu]

The point was that there is one PHP file containing one string. I am attaching the directory as a Zip file, in case it helps.

php-test.zip

I was expecting poedit to detect the only call to _(), extract the string and provide room for translation. That's the way it has always behaved for the previous 5+ years, in multiple projects, on multiple computers. Given that now I cannot convince poedit to pick up one single string from one single file, and given that I spent 4 hours to distill everything down to this, it felt appropriate to open an issue for posterity.

[vslavik]

That's the way it has always behaved for the previous 5+ years

The sample you provided works just fine.

So it's something weird with your environment (e.g. files not readable for the Poedit process) or broken gettext tools etc. Did you do basic diagnostics, such as clicking the Details button as the message tells you? What does it say? Did you try running xgettext manually (e.g. xgettext -o lib/*.php) to see what happens? Is xgettext on PATH? Did you try the official snap packages from http://poedit.net/download ?

If none of the above provides any clue, see also poedit --help; in particular --verbose may show something. Try this:

$ export WXTRACE=poedit,poedit.extractor,poedit.execute
$ poedit --verbose ro_RO.po 

[CatalinFrancu]

Wow, this is a goldmine! I am unfamiliar with the underlying stack. Perhaps you could add this information, especially the bit about WXTRACE, to SUPPORT.md or to the FAQ.

• xgettext lib/*.php seems to work. It creates a messages.po file with the extracted string.
• the Details button only reports the message I've copied above (Translation entries in the file are probably incorrect.).
• The snap packages do work.
• The --verbose flag only adds one popup at startup: _using catalog 'poedit' from '/usr/share/locale/en_GB/LCMESSAGES/poedit.mo'. This seems to refer to Poedit's own translations.

What really helped was running what you suggested:

$ export WXTRACE=poedit,poedit.tmp,poedit.extractor,poedit.execute
$ poedit --verbose --keep-temp-files ro_RO.po 

This produces output which shows that a temporary file, gettext.pot is being created, but then execution never moves on to msgmerge (which the snap version did do).

I've compiled Poedit from scratch and added some debug messages. In my case, adding return pot; after creating this variable seems to fix things. I'm still not sure why this works out of the box for everybody else. 🤔 I can work with this patched version or with the snap package.

Thanks again for Poedit!

[vslavik]

Wow, this is a goldmine! I am unfamiliar with the underlying stack. Perhaps you could add this information, especially the bit about WXTRACE, to SUPPORT.md or to the FAQ.

I should add at least some of that output to --verbose but other than that, this is straight in debugging territory. I was certain there was some issue with the gettext binaries in your setup.

In my case, adding return pot; after creating this variable seems to fix things.

...but it was refactoring/backport gone wrong and I didn't see it because a) no compiler warning (not sure why) and b) I was on a different branch.

You're 100% right, that missing return pot after is the bug.

I'm still not sure why this works out of the box for everybody else.

It doesn't, but it's only observed in distro packaging of 3.3.1 (3.3 was fine) and we're only now seeing it hit.

So, thanks a lot for fixing it! I'm going to release 3.3.2 shortly.