Page MenuHomePhabricator

Add "inlanguage" field in advanced parameter form
Closed, ResolvedPublic8 Estimated Story Points

Description

Motivation
At the wikis that use Extension:Translate, it would be great to teach people that we can limit the search results to a specific language using the inlanguage:foo parameter. E.g.
https://meta.wikimedia.org/w/index.php?search="Meta+serves+three+distinct+roles"+inlanguage%3Aen
https://meta.wikimedia.org/w/index.php?search="Meta+serves+three+distinct+roles"
because it is often very hard to find a string of text when it appears in hundreds of translated/semi-translated pages.

Mock
Please use the location and label as indicated in the mock

Screenshot_20180222_181608.png (694×1 px, 87 KB)

Info i texts

InlanguageInfotext.png (615×668 px, 105 KB)

TEXT FOR COPYING:

Pages in this language:
Description: Will only search in the language you choose.
Be aware of the following:

  • You can only search for pages in one language.
  • This field will only be visible in wikis that have the translatewiki extension enabled.

Help page: Inlanguage
Syntax-Equivalent in the normal search: inlanguage: followed by a language code like inlanguage:es. You can exclude languages by adding a - in front of the keyword e.g. -inlanguage:en.

Acceptance Criteria

  • If the wiki does not support the translate extension, the field/label is not visible
  • If the wiki supports the translate extension, there is a field with label and info text as indicated in the mock/ticket
    • The field uses the same input method as file type
    • The presentation of languages and the list of languages should be consistent with the rest of wp, eg. https://de.wikipedia.org/wiki/Spezial:Einstellungen --> Internationalisation/Languages
    • The default of the field is "Select language", which can also be selected from the list. If "Select language" is selected, this keyword is ignored
    • Searching with this field reduces the search results to only this language (i.e. we use the inlanguage keyword correctly)
  • the use of inlanguage should be tracked and added to the schema. The fact if inlanguage was offerered to the user at all should be tracked in a separate property (according to @GoranSMilovanovic)

Notes
-We assume but need to make sure that this is reality: Content wise you can select the same languages as interface wise (e.g. seperate between different types of German)

Related Objects

Event Timeline

There are a very large number of changes, so older changes are hidden. Show Older Changes
Lea_WMDE renamed this task from Autosuggest languages in advanced parameter form to Add "inlanguage" field in advanced parameter form.Feb 14 2018, 10:41 AM

@Charlie_WMDE nitpick: Should the title be as shown in the mock or as described in the text below? Can you update one of them? :)

@Charlie_WMDE are you sure you want to use "Add language" instead of "Choose language"? During storytime it was indicated that "add" implies that you can add multiple ones (and for namespaces you can), but you can only select one language

Note: I've fixed the task-description's "Text for copying" section, with 1 spelling correction and 1 improved link.

@Lea_WMDE I don't see this as a big problem, hence I picked add seeing that it is consistent with the wording we already use. I do understand your point though. Since convention seems to be to use "select" I suggest we use that. I have updated the mock accordingly.

@Charlie_WMDE thanks!
@Pablo-WMDE @gabriel-wmde @Tonina_Zhelyazkova_WMDE from my side, all questions from storytime have been solved here. I only don't understand the comment that inlanguage needs to be in a different property (@GoranSMilovanovic ), and therefore just want to make sure that this keyword will not be treated differently, but counted and compared like all the other keywords, right?

Change 414974 had a related patch set uploaded (by Tonina Zhelyazkova; owner: Tonina Zhelyazkova):
[mediawiki/extensions/AdvancedSearch@master] [WIP] Add search field with the functionality of inlanguage keyword

https://gerrit.wikimedia.org/r/414974

Note:
The Translate extension is part of Language Extension bundle. There's something called Universal Language Selector in there. Might be helpful if we want to further configure the looks of the inlanguage dropdown.

Change 416479 had a related patch set uploaded (by Tonina Zhelyazkova; owner: Tonina Zhelyazkova):
[mediawiki/extensions/AdvancedSearch@master] Add unit tests for FileTypeSelection

https://gerrit.wikimedia.org/r/416479

Some explanation regarding the second branch relating to this ticket:

  • After implementing inlanguage functionality it was decided it's better to re-factor FileTypeSelection.js class.
  • After refactoring it was realized there are no unit tests for FileTypeSelection.js therefore we have no way of knowing if we broke something.
  • After writing tests for the old version of FileTypeSelection it was noticed that some other unit tests are failing. The tests need re-factoring inline with some changes to AdvancedSearch.
  • After all this is resolved we can go back to actually writing tests for the changes regarding inlanguage.

p.s. I'm deep down the rabbit hole.

Change 416479 merged by jenkins-bot:
[mediawiki/extensions/AdvancedSearch@master] Add unit tests for FileTypeSelection and FileTypeProvider

https://gerrit.wikimedia.org/r/416479

Update:

The browser tests related to inlanguage currently fail on jenkins because there's no Translate extension.
I personally don't think it's ok to add a check to the tests, because they would never run on jenkins this way.
Any ideas how to tackle this?
@gabriel-wmde @thiemowmde @WMDE-Fisch

Change 420000 had a related patch set uploaded (by Tonina Zhelyazkova; owner: Tonina Zhelyazkova):
[integration/config@master] AdvancedSearch depends on Translate extension

https://gerrit.wikimedia.org/r/420000

Change 420000 merged by jenkins-bot:
[integration/config@master] AdvancedSearch depends on Translate extension

https://gerrit.wikimedia.org/r/420000

Change 420065 had a related patch set uploaded (by Gabriel Birke; owner: Gabriel Birke):
[mediawiki/extensions/AdvancedSearch@master] Improve dropdown tests

https://gerrit.wikimedia.org/r/420065

Another update:
Solution to browser tests failing on the CI server due to lack of Translation extension is to add the dependency in integration/config/zuul/parameter_functions.py
It's added now https://gerrit.wikimedia.org/r/420000 and tests pass. *whew*
End of monologue ( and agony ).

Change 414974 merged by jenkins-bot:
[mediawiki/extensions/AdvancedSearch@master] Add search field with the functionality of inlanguage keyword

https://gerrit.wikimedia.org/r/414974

so I checked this on the test wiki, and it looks good in general, however there are quite a few things I did not manage to check:

  • Is the field only visible on wikis that have the translate extension enabled?
  • I think all pages are categorized as German on the wiki, at least that is the behavior I got. I could only test that it found all pages (independent from the actual languages used on teh page) when using inlanguage:de, but not with inlanguage:en

@Lea_WMDE

  • We would need two different test wikis to show that. I can turn on and off the Translate extension either in my dev environment or on the test server for you to see if the languages dropdown disappears.
  • A new page named Test ( content Versuch ) was created on the test wiki. The title is translated in Bulgarian. So now if you look for pages in bg, or Versuch in bg, you'll get that result ( Тест ).

Change 420065 merged by jenkins-bot:
[mediawiki/extensions/AdvancedSearch@master] Improve dropdown tests

https://gerrit.wikimedia.org/r/420065