conflicting with contact or in contact?
"Conflicting Contact:"

could be there plural forms?
"Opening %d contacts will open %d new windows as well.\n"
"Do you really want to display all of these contacts?"

what unclassified? note, user, account?
"Unclassified"

http://live.gnome.org/TranslationProject/DevGuidelines/Use%20comments

also here are plural froms needed
"Folder '%s' contains %d duplicate messages. Are you sure you want to delete them?"

we have different translations, like "Nasledujuci %a" (Mon., Tue., Thu., Fri.), "Nasledujuca" (Wed., Sat., Sun.)
"Next %a"

comment #0 - done
comment #1 - done (some hopefully clarifying text added, though when seen in the UI itself it may have get more sense).
comment #2 - nope, it's shown for more than 5 items. or you mean to add ngettext for languages where they can change words for different digits?
comment #3 - done. Security level. I added "Security" context to it, same as for other in the list from that file.
comment #5 - similar to comment #2
comment #6 - hmm, no idea how to help here; I would use "Příští" or for you better "Ďaľší"?

Created commit ce02a16 in evo master (2.91.4+)

#2; #5 - yes, we don't need if number is higher than 5, but someone else do

#6 - nope, we can have "Dalsi" and "Dalsia", could it be "Next Thu.", "Next Fri.", so on (7 strings)

thanks

(In reply to comment #8)
> #6 - nope, we can have "Dalsi" and "Dalsia", could it be "Next Thu.", "Next
> Fri.", so on (7 strings)

That's a thing I wanted to avoid. I wanted to reuse translations, rather than add new. Can I workaround this anyhow? What about ngettext it too, with a value between 0 ad 6, with an explanation (translators comment) what each value means, and in sources use basically ngettext("Next %a", "Next %a", day_of_week)?

hmm, there will be
msgstr[0-6]?

I am not a dev

You will have an option to define msgstr[0] .. msgstr[6] for this string, yup. I'm afraid that there is nothing better at the moment I would suggest.

Thanks, I thought that it has to behave by plural forms rules

ad 5) aah, there was a typo in the code, there was used
> ngettext (_("text"), _("text"), x)
instead of
> ngettext ("text", "text", x)

I fixed it, same as the rest of this bug.

Created commit 081ee1a in evo master (2.91.4+)

thx

Sorry to reopen, but the solution to #6 is plainly wrong. Translators cannot choose msgstr[?] at their will. It has to respect the plural form equation corresponding to the language. If your language has two plural forms, it has to use msgstr[0] and msgstr[1] (in this particularly case, 0 will be used for Monday (singular) and 1 for Tuesday to Sunday (plural)).

I see only two solutions:

- either have only one translation as before and the translator has to find a form wich is suited for all days (maybe using another formulation).
- Use msgctxt (C_ macro) and add a different translation for each day.

Do you mean that if your language has only msgstr[0] and msgstr[1] (like in your example above), then you cannot write an exception for msgstr[3]? It sounds pretty unlikely to me, such heuristic would be quite hard to do in gettext, from my point of view. It's like writing order numbers in text, "1st", "2nd", "3rd", "4th" - there is no difference from the code point of view, or at least I do not see it.

Obviously, the msgstr indexes for a plural string translation has to match the plural form equation in the top of your file. If your plural equation specify two forms (nplurals=2; plural=n>1;), msgstr[1] will be used for n>1, msgstr[0] for all other cases. How could gettext guess for which case should msgstr[2] be used?
Anyway, msgfmt -vc check would report it as an error:
$ msgfmt -vc -o /dev/null po/fr.po
po/fr.po:29: nplurals = 2...
po/fr.po:826: ...but some messages have 3 plural forms
msgfmt: found 1 fatal error

(In reply to comment #18)
> Obviously, the msgstr indexes for a plural string translation has to match the
> plural form equation in the top of your file. If your plural equation specify
> two forms (nplurals=2; plural=n>1;), msgstr[1] will be used for n>1, msgstr[0]
> for all other cases.

Ah, I didn't notice there's a rule for it at the top of the .po file.

> How could gettext guess for which case should msgstr[2] be used?

Based on the index 'n', I hoped. But I was wrong, as you showed me. I'm fixing this in master.

Thanks for letting me know. I guess there was no better option than duplicating the translation of abbreviated day names in evolution, which I wanted to avoid initially.

Created commit 9afe9af in evo master (2.91.91+)

Thanks Milan, I think you choose the better solution regarding translation, even if from a coder point of view it may appear redundant.

#: ../mail/em-account-editor.c:2578
msgid "minu_tes"

could you add plural forms?

Pavol, please open a new bug report as this one is already too crowded.

For what it's worth, it does not make sense to use plural form for the "minu_tes"
string as it comes after a spin widget, so the number is not known in advance and can change depending on user input.

sorry, I will open it next time

yes, but can be there value lower than 5?

we have

4 minuty
5 minut
10 minut
1 minuta

so we needs more variants, changing value in spinbox should change string

No.  The string is fixed in a GtkLabel.  It does not change with the spin button value.  Just assume it's >= 5.

if it is higher than 5 min., so no problem