latest trunk

some interesting link http://mel.melaxis.com/devblog/2006/04/10/benchmarking-php-localization-is-gettext-fast-enough/

hmm. for that specific string, i'd argue there is no need to use _s at all - it has no placeholders and thus only uses one sprintf call needlessly (and additional internal function call)

would be nice to check whether there are other cases like that as well and remove _s use from all of them

i wanted to add _s inclusion already before, just didn't get to it yet - added now

as for obsolete strings, this is something to be discussed. i propose to keep them in for now and return to this discussion once we have worked with gettext solution for a while

README should be corrected regarding to automatic creation of POTFILES.in .

I want to draw attention to an important point.
You need to promptly correct the PO files.
Is meant to add a line to header of PO files (different for each locale):
"Plural-Forms: nplurals=3; plural=(n%10==1 && n%100!=11 ? 0 : n%10>=2 && n%10<=4 && (n%100<10 || n%100>=20) ? 1 : 2);\n"
this is for Ukrainian and Russian for example.

Why? Answer -
if we now update the files using 'update_po.sh' then you receive plural forms in ALL locales something like:

#: ../config.php:883
#, php-format
msgid "Delete selected value mapping? It is used for %d item!"
msgid_plural "Delete selected value mapping? It is used for %d items!"
msgstr[0] ""
msgstr[1] ""

But this is wrong. Even if you add correct Ukrainian "Plural-Forms:..." to PO header and run again 'update_po.sh' it is not helped - in PO file leaving only two forms:
msgstr[0] ""
msgstr[1] ""

As result the GUI editors (Poedit, Virtaal) not present an interface to correct translation plural.

Correctly for Ukrainian and Russian these three forms, witch automatically generated for the founded new _n() if correct header is defined:
msgstr[0] ""
msgstr[1] ""
msgstr[2] ""

NOTE - Poedit perfectly presents numerical examples for each form according to locale of PO file, Virtaal without examples, but all three forms simultaneously.

So, you must to add promptly the correct "Plural-Forms:..." to header of each locale.

readme corrected;
update_po.sh now also grabs _x functions... except that the function supposedly is not implemented yet - it should be. probably will be handled in this issue then

About string location references.
Now string references, generated by 'update_po.sh' from latest trunk visible like:
#: ../include/forms.inc.php:392

But if i manually change to this:
#: ../../../include/forms.inc.php:392
then Poedit gives me ability to the context menu easily open and select source code file directly at line with translated string. Even in Windows.
See picture "reference_path.png".
Virtaal do not have this is functionality

About my previous post with text "- in PO file leaving only two forms:"
It seems my English is bad, i'm sorry.
I mean that - in the PO file is still present only two forms, but the third form (msgstr[2] "") is NOT added.

And as I said earlier, all three forms will be correctly added only for the newly found _n() functions.

So I prepared a patch to correct the plural in all locales.
All headers taken from 'msginit' command output.
All checked according to http://www.gnu.org/software/gettext/manual/gettext.html
Chinese (zn_CN) header is taken from WordPress translation and it correspond with http://translate.sourceforge.net/wiki/l10n/pluralforms#z

For forgotten Japanese from ZBX-3331 use the headers:
"Language: ja\n"
"Plural-Forms: nplurals=1; plural=0;\n"

please, review

Looks good

plural forms added, thanks.
we're doing a bit of a parallel work every now and then, though
i had already started adding them, but then you commented that you will attach a full patch...

No answer or action for my comment "About string location references." then reopen, sorry
Additionally, maybe it is not important but i'm noticed that Poedit has configuration option: Catalog -> Settings... -> Path tab -> Base path:

If i write Base path: as ../../ then the functionality presented in the picture "reference_path.png" works well.
After save a catalog (PO file) it has an additional header:
"X-Poedit-Basepath: ../../\n"

Of course this is related only for the Poedit (i'm tested only Poedit and Virtaal) and may be this idea will be discarded by you, but maybe it better to include this header in all locales and close thread about path for string location references. At you decision.

About references to source code.

Richlv likes to see diff for new translation file, but sometimes it gives a false result. What I've noticed:

FIND command on different servers, even on the same operating system provides a list of files in a different sequence (POTFILES.in).
As a result, for example, after updating by 'update_po.sh' script I get this:
#: ../chart4.php:87 ../chart5.php:90

instead of this:
#: ../chart5.php:90 ../chart4.php:87

I suggest adding sorting to the 'POTFILES.in'. This works:
find .. -type f -name '*.php' | sort > POTFILES.in

I noticed differences between FreeBSD and Linux 'sort' work.

Example -
freebsd:
../api/classes/class.cgraph.php
../api/classes/class.cgraphitem.php
linux:
../api/classes/class.cgraphitem.php
../api/classes/class.cgraph.php

Example (upper-lower case) -
freebsd:
../tests/selenium/SeleniumTests.php
../tests/selenium/class.ctest.php
linux:
../tests/selenium/class.ctest.php
../tests/selenium/SeleniumTests.php

If i add both of flags -d -f for 'sort' command then FreeBSD=Linux.
NOTE: in the Linux sorting WITH those flags is not changed, but in the FreeBSD sorting becomes the same as in Linux.

man sort:
-d, --dictionary-order
consider only blanks and alphanumeric characters
-f, --ignore-case
fold lower case to upper case characters
....

So i propose to use
find .. -type f -name '*.php' | sort -d -f > POTFILES.in

I noticed that fuzzy strings in not inserted to .mo file
According to GETTEXT documentation by default 'msgfmt' don't use fuzzy strings, for force inclusion is available --use-fuzzy flag:

‘--use-fuzzy’
Use fuzzy entries in output. Note that using this option is usually wrong, because fuzzy messages are exactly those which have not been validated by a human translator.

I'm think in our case that they should be included.
Richlv seems too:
[00:03] Richlv: zalex_ua, ah. hmm. i guess they should be included ?

fuzzy entries should be now included in mo files - reasoning being that we don't do automatic fuzzy matching, so fuzzy entries would be marked by translators. as such, they are not expected to be awfully wrong and would contribute to the translation being more complete

for the record, sorting was also added to the script

it would be nice to summarise what other problems are still there, and once they are solved, close this issue & deal with other problems in new issues.

1. _x() missing;
2. file references in po files to be figured out

anything else ?

1. _x() missing;
I think better place to resolve is ZBX-3271

2. file references in po files to be figured out
I propose simply add the header:
"X-Poedit-Basepath: ../../\n"
to each locale and then close this issue.
Now this header is included to UK and RU locales.

X-Poedit-Basepath header added to all locales