latest trunk with Gettextization.

I tried some modification:
//GETTEXT: Time unit. Short of 'minute'
(($minutes && !$years && !$months && !$weeks)?$minutes._x('m', 'time_unit').' ':'').

Result:
Fatal error: Call to undefined function _x() in /usr/local/www/zabbix/include/func.inc.php on line 310

As Richlv said - "currently not supported" in the
http://www.zabbix.com/documentation/2.0/contrib/frontend_localisation#code_conventions

So, perhaps is time to write this function _x() and I will make some patches to fix step by step problems i described in the Description?
Who else besides me is willing to suffer with corrections for translations?

I would ask to perform this issue ASAP. Because we need additional time before the 2.0 release to figure out all possible places where this problem can be visible.

For instance, try to open calendar in the Russian locale and see to the day's names . After implementing this function I'll be ready to try find such places and prepare the patches.

I believe there are 2 ways we can solve this:
1. The easy way - http://www.php.net/manual/en/book.gettext.php#89975
2. Or we can change our translation structure to contain multiple directories, e.g. (main, time, months etc.) and use them as contexts. This will require a bit more sophisticated translation updating script, but may have other benefits, like increasing ease of translation and reducing error count.

Secondly, do we need another _x() function? Maybe we can introduce a single universal wrapper, like __($string, $args = array(), $context = 'main')?

I vote for the way #1

Multiple .po files will be not very convenient for translators too.

For short messages like "m, h, s" you can write the special gettext comments in the source code, and they will be automatically included in the .po files and will be visible for translators in the Pootle, and in the other applications for translation.

If I understand correctly the function _x() would be better (more convenient) than universal wrapper.

the problem is that 2. alone would not be enough - many terms will have context based on where they appear in the frontend, which would be impossible to realistically cover with categories. categories also seem like really complicate thing to maintain (although i haven't used such approach before). so i'd vote for 1.

as for function, we currently use this approach with _s and _n, thus it kinda makes sense to be consistent. also, gettext tools recognise and parse such things outofthebox - not sure how a different wrapper scheme could be used - haven't tried that before either

<pavels> What do you mean not enough? Both 1. and 2. will provide exactly the same functionality, they will assign a string to a single context. The only question is, how will we store them. I'm not sure we actually need folders, because, from my previous website i18n experience, very few terms actually need separate context (mostly shortenings and rare homonyms). If you don't think, that organizing translations in separate folders would be more convenient from translations, then it's probably not worth the effort.
The manual says you can specify, witch arguments contain the term, and witch - the context. Haven't tried it yet, though.

<zalex>
I think Zabbix front-end differs from many other websites.
Here is used big count of terms which are requiring separate context. I as translator know that very well.

Ok, if everyone votes for #1, #1 it is.

Seems to be working fine. RESOLVED.

for the record, available in svn://svn.zabbix.com/branches/dev/ZBX-3271

(1) http://www.zabbix.com/documentation/2.0/contrib/frontend_localisation#disambiguation_by_context should be reviewed and updated, if necessary

<pavels> CLOSED.

(2) [GUI]
I changed arguments order and added support for parameters placeholders, review please.

<pavels> CLOSED.

(3) added _xn parsing for po updating script - please, review

<pavels> CLOSED.

Merged to trunk revision r23195. CLOSED.