1

I have a website that is internationalized using php's built-in Gettext / PO support

echo _("string to be translated");

The site being in beta, there are certainly some strings that don't get translated. To help debugging, is there a way to log gettext errors, i.e. log strings for which PO has not found any matching entry in the PO file?

David
  • 1,898
  • 2
  • 14
  • 32
  • 1
    You should be *automatically* extracting all i18n'ed strings into a .po file using appropriate tools, then look at those files using localization tools like POedit. This shows you which strings still need translating and all strings should be in the files because the extraction has been automated. – deceze Sep 21 '12 at 14:31
  • so there's no way to log gettext errors? with constant changes to the code base, errors may appear over time – David Sep 21 '12 at 14:39
  • Not as far as I know (but I'm no expert on gettext). It's specifically not considered an error to find no localization in gettext. I would also not consider logging a good way to find non-translated strings, since it means you have to run all the code paths where translations occur to find untranslated strings. That's a lot less manageable than having a good workflow for extraction set up. – deceze Sep 21 '12 at 15:15
  • By the way, what tool would you use to automatically extract all strings to be translated from a PHP script? – David Sep 23 '12 at 18:59
  • 1
    The default is xgettext from the gettext tool chain. – deceze Sep 24 '12 at 07:49

2 Answers2

7

The problem with what you want to do is that you'll only find untranslated strings at runtime, and only for code paths which are actually executed. It may take years for you to find all strings, and in the meantime you have to look at your log files regularly and sync your updated translations with what's happening in the log file. That's not a deterministic approach to translations.

If you're using gettext, you need to establish a workflow that's appropriate for it. And the gettext workflow and toolchain are pretty well thought out and time tested.

  1. Prepare your source code by wrapping strings in gettext functions.
  2. Extract the prepared strings into POT files, typically using xgettext but possibly using a custom parser/extractor and a library like Kunststube\POTools (shameless self promotion).
  3. Create PO files from the extracted template files using msginit.
  4. Translate the PO files.
  5. Keep updated source/POT files in sync with PO files using msgmerge.
  6. Compile PO files to MO files using msgfmt.
  7. Rinse, repeat.

This is the proper gettext workflow in a nutshell, and it accounts for most problems in the translation process. Especially if you have distributed translators you typically have a time lag and overlap between source code being updated and translations coming in. Without automated string extraction and the msgmerge utility it's easy for this process to devolve into chaos, which is why you should stick to the above steps.

If you do, your question becomes irrelevant since you can check your PO files at any time using the gettext utilities or a tool like Poedit to see which strings are untranslated.

deceze
  • 510,633
  • 85
  • 743
  • 889
  • most probably this will not solve all issues someone could have with translations. Assume you have configurations where you define a string that you need to translate later (not when the configuration is parsed). To extract all string constants in your code is maybe a bad idea (all keys of objects/assoc arrays) and to translate the at configuration level means to cache the config locale specific. Of course for the most translations you find calls to gettext but not for all. A logging mechanism makes sense. – iRaS Feb 22 '19 at 09:08
0

Probably more important as your in beta would be to do some pseudo localisation, using a tool like podebug. Thus once you've extracted your PO strings you can localise them so that you can see if all strings are extracted in your UI.

Dwayne
  • 845
  • 7
  • 11