Page MenuHomePhabricator

More search options for Special:SearchTranslations: type,status, lang, grp, case
Closed, ResolvedPublic


A translator may know the exact kind of special search to perform. For this, the translator should have an option for an advanced search to get more specialized results from the tool. Searching with parameters:

  • type (default is msgall): This gives the type of search.
    • "key" for message-key searches
    • "exact" for exact matches
    • "msgany" to match any word in the query string
    • "msgall" to match all words in the query string
  • status (default is all): This gives the status of result messages.
    • "all" for all messages
    • "translated" to match translated messages
    • "untranslated" to match untranslated messages
    • "outdated" to match outdated messages
  • lang (default from ULS): This gives the target language of the search as 2 letter code. e.g. de for German, fr for French and so on.
  • grp (default is all): This gives the message group that's selected for the search. e.g. MediaWiki, MediaWiki (core) etc.
  • case (default is false): This gives whether the search is case sensitive or not.


Screenshot_from_2015-03-23_03:45:46.png (539×959 px, 81 KB)

Along with this, the search will have autosuggest for tag values.

Screenshot_from_2015-03-30_16:52:26.png (434×731 px, 30 KB)

Event Timeline

Phoenix303 raised the priority of this task from to Needs Triage.
Phoenix303 updated the task description. (Show Details)
Aklapper renamed this task from Advanced search options for Special:SearchTranslations to More search options for Special:SearchTranslations: type,status, lang, grp, case.Mar 23 2015, 9:52 AM

I would like to see user scenarios backing these requirements. Personally I just search first and use the facets to filter down the results if needed.

I personally think it will be nice being able set the values that currently appear in the facets after the search prior to the search. This is because I usually only want to get results for MediaWiki and in the language I translate to. 100% of my searches are messages I have seen live which need to be enhanced by some kind.

I think it should be a good initiative.

Thanks for working on this feature! I have a question:

Will those search parameters appear as a (faded out) prompt (a.k.a. placeholder text) inside the field? Or are the mockups showing text typed by the user only? Either way, I think the search parameters should be discoverable right in the UI, without having to open a separate help page. Maybe it’s a good idea to add a help balloon next to the search field, which would contain the list of available parameters and a brief description of what they do.

Thank you all for your feedback.

@Fito The mockup shows text entered by the user and thank you for suggestions to support placeholder text and help tooltip. This mockup is not a final design and more features can be added based on feedback.

As agreed, Phoenix will file three (kinds of) subtasks for this:
a) adding operators for filters which already exist (like language and group)
b) adding new filters and corresponding operators, which probably require ElasticSearch index changes (like message key, type, case)
c) status searches, e.g. "outdated translation containing word", with any further subtask for API dependencies or "cross language search" overlaps (e.g. "message key untranslated in language X", in addition to the standard "source message containing word X untranslated in language Y which is T55656)

All subtasks are resolved hence assuming this task is also resolved. If it is not, please reopen and elaborate what is needed, plus update/unset the assignee. Thanks.