View Issue Details

IDProjectCategoryView StatusLast Update
0018612phpList 3 applicationInternationalization (l18n)public29-01-18 20:39
Reporterduncanc Assigned To 
Status resolvedResolutionfixed 
Product Version3.3.1 
Summary0018612: Incorrect translation
DescriptionAn odd result of translating a piece of text

In processbounces.php

    outputProcessBounce(s('%d bounces to fetch from the mailbox', $num).PHP_EOL);

is being displayed as

bounces to fetch from the mailbox

i.e. is missing the number of bounces.

Looking at the i18n table, the %d has been removed from the translated text, see screenshot.

The translations appear to be up to date on the Update Translations page. This is on an installation that has been updated several times.

I then looked at a clean installation of release 3.3.1 and that does not have that particular translation item at all. That installation too is up to date on the Translations page.
TagsNo tags attached.


has duplicate 0018742 assignedbacklog Process bounces message omits number of bounces 



02-04-17 10:57



03-04-17 08:23

updater   ~0058945

Looking at the .po file, that is the source of the error.

#: public_html/lists/admin/processbounces.php:389
#, php-format
#, fuzzy, php-format
msgid "%d bounces to fetch from the mailbox"
msgstr "bounces to fetch from the mailbox"

But the other site doesn't have the translation item at all. That site was actually a clean install of 3.2.7 followed by an upgrade to 3.3.1 (bypassing 3.3.0). It appears that the upgrade process doesn't include updating the translations.


03-04-17 09:11

manager   ~0058946

Is this a feature request to trigger an automatic update of translations when a version change is detected?


04-04-17 09:30

updater   ~0058952

No, I tried to repeat what I had done on the other server, installing 3.2.7 then upgrading to 3.3.1, and the "missing" translation was present.

phplist seems to automatically try to update translations when it fails to find a translation in the i18n table. So if a phplist upgrade introduces new translations they will be loaded when first used.

But the .po file looks to be wrong, unless someone has deliberately removed the %d.


04-04-17 12:05

manager   ~0058953

Presumably the .po should not include placeholders like %d however? Is this a mistake in the string name?


04-04-17 12:29

updater   ~0058954

Lots of translation items include %s, %d etc.

Is there an audit log of changes to the translations?


04-04-17 12:56

manager   ~0058955

Assigning to Michiel. In the Pootle web interface, some strings have a link to "view timeline", but most do not. I'm unsure whether there is a formal change or audit log.


16-01-18 15:09

updater   ~0059842

Can this translation be fixed? All that is needed is to put the %d back into the translated text.


16-01-18 15:25

manager   ~0059843

@duncan done:,target


16-01-18 19:26

updater   ~0059847

Thanks. Will that be included in a new translation build automatically? Do those happen overnight?


16-01-18 19:33

manager   ~0059848

@duncanc It will happen automatically, but I'm not sure of the current frequency. Should be within a few days at most.


24-01-18 09:47

updater   ~0059904

This change has not yet appeared as a language update within phplist but there have been language changes this month. From

<translation><iso>sq</iso><name>sq</name><lastmodified>1515966051</lastmodified><modified>2018-01-14 21:40</modified><updateurl></updateurl></translation>

<translation><iso>gl</iso><name>gl</name><lastmodified>1516542461</lastmodified><modified>2018-01-21 13:47</modified><updateurl></updateurl></translation>

@michiel please can you explain how a language change is processed and made available as a language update within phplist?


28-01-18 11:41

administrator   ~0059910

phpList fetches every so often and then compares the output with the local details to determine if there's a language change. But I do think things get cached left right and center, so it will require all caches to expire before it's detected.


28-01-18 11:43

administrator   ~0059911

What might be a nice addition to avoid this issue, is to update the "s" function to reject a translation that doesn't match the sprintf placeholder of the original. Eg "%d bounces to fetch from the mailbox" requires at least a %d in the translation and otherwise it'll continue with the original.


28-01-18 13:12

updater   ~0059912

What I meant was how is a change to a translation processed?

Sam made a change on 16 Jan that does not seem to have been processed. If you view in a browser then the English translation was modified on 14 November. But there have been translations for other languages processed since 16 January, see my comment on 24 January.

The translation process already reports on translations with mis-matched printf placeholders, so that should be caught anyway, so long as there is some manual review of translation changes.


28-01-18 13:33

administrator   ~0059913

The file is actually a PHP script that checks the database of the Pootle system. Pootle is a Django/Python based system, and tbh, I'm not entirely sure how it handles it's stuff. Some of it is in the po files and then there's a sync to the Database. I'll have a look to see if the syncing has stopped or something.


28-01-18 14:01

administrator   ~0059914

Ok, indeed, something was wrong on the python system. I found this that may have fixed it:

I'll run a few tests now


28-01-18 14:03

administrator   ~0059915

chown www-data: translations/ -R

I don't get any more errors when running the crons, so I think it's ok now. Let's check and verify in a few days.

FYI @samtuke @martin


28-01-18 15:51

updater   ~0059917

That has worked for me.
phplist showed an update available for English and, after applying the update, the "bounces to process" message was correct.


28-01-18 19:12

administrator   ~0059919

great, thanks for confirming


29-01-18 14:52

manager   ~0059926

Documentation about this process should be added to the public resources docs. Assigning to @xheni for investigation and documentation.


29-01-18 20:39

administrator   ~0059930

Not sure this is documentable. I think we should rebuild the translation server with Ansible.