Fix header of search result sections (RhBug:1301868)

[jrohel]

Header of the section will be correctly denote its content.
examples:

• Name Exactly Matched: ...
• Name & Summary Matched: ...
• Name Matched: ...
• Summary Matched: ...

[jrohel]

Test this please

[piotrdrag]

Do I understand correctly that this causes, for example, “Name” to be concatenated with “Matched”, displaying “Name Matched” in the UI? If so, then it makes i18n very difficult for many languages: https://wiki.gnome.org/TranslationProject/DevGuidelines/Never%20split%20sentences

[jrohel]

Do I understand correctly that this causes, for example, “Name” to be concatenated with “Matched”, displaying “Name Matched” in the UI?

1. Set of attributes (name, summary, description, url) is transated. (Translation of this attributes exists in dnf for some time)

2. There are 2 messages for translation: '%s Exactly Matched: %%s' and '%s Matched: %%s'.
   %s is replaced by set of translated attributes (for English: Name, Summary, Name & Summary, ...)
   %%s is replaced by found keywords
   So, order of words is defined by translators.
   For better translation I can make change. I can use plural forms (number of attributes will be used as parameter).
   Eg. this will be possible: P_("Attribute %s contains: %%s", "Attributes %s contain: %%s", num_of_attrs)
   I can change attributes separator '&' to another char, If you have better idea.

3. And finally. Yes. I can change code and prepare message for every combination of attributes and text Matched/Exactly Matched. It is 32 combinations/messages now. Where is the limit for using static messages. 20, 100, 1000 ...
   This is what you want?

Examples of generated group headers in English:

================ Name Matched: clang, analyzer =================
================= Name Exactly Matched: clang ==================
================ Name & Summary Matched: clang =================
========= Description & Name Matched: clang, analyzer ==========
============== Description & Name Matched: clang ===============
===== Summary & Name & Description & URL Matched: analyzer =====
========= Summary & Name & Description Matched: clang ==========
============ Summary & Name & URL Matched: analyzer ============

...

[piotrdrag]

OK, so it’d work for languages other than English if you:

• make “&” translatable, as not every language uses the ampersand,

• mark “Name”, “Summary”, “Description” and “URL” with context, so they can be translated differently than in other places, e.g. accusative here, while retaining nominative elsewhere: https://wiki.gnome.org/TranslationProject/DevGuidelines/Translation%20contexts

• add translator comments, so they can know to reorder the verbs according to their language’s grammar and decline the nouns, if needed: https://wiki.gnome.org/TranslationProject/DevGuidelines/Use%20comments

[j-mracek]

@dnf-bot r+

[dnf-bot]

📌 Commit 9130a98 has been approved by j-mracek

[dnf-bot]

⌛ Testing commit 9130a98 with merge ef436ec...

[dnf-bot]

☀️ Test successful - status-jenkins
Approved by: j-mracek
Pushing ef436ec to master...

[piotrdrag]

It’s much improved now, thanks!

Any chance of using C_( ) for the attributes?

[jrohel]

Any chance of using C_( ) for the attributes?

DNF code (Python) uses only two functions for translation now. _() - gettext() and P_() - ngettext().
The translation with context C_() isn't supported in DNF. So I think that using C_() for attributes is not possible until C_() is not implemented.