Page MenuHomePhabricator

Inform users what happened if their query is forwarded to another wiki because of language detection
Closed, ResolvedPublic

Description

See attached mockup for spec agreed upon by product and design:

Details

Related Gerrit Patches:
mediawiki/core : wmf/1.27.0-wmf.4Styling tweaks for inline interwiki search
mediawiki/core : masterStyling tweaks for inline interwiki search
mediawiki/core : masterDisplaying search results for multiple wikis
mediawiki/extensions/CirrusSearch : masterDisplaying search results for multiple wikis
mediawiki/core : master[WIP] Displaying search results for multiple wikis
mediawiki/extensions/WikimediaMessages : masterAdd messages for multiwiki search

Event Timeline

There are a very large number of changes, so older changes are hidden. Show Older Changes

The same by language, not by wiki: http://tinyurl.com/o6dexh7

English is first with 282 (all) wikis, next is French, Italian and Dutch, surprisingly German is way behind with 91.

That seems pretty good my untrained eye. The full list of labels is more complete than i expected: http://tinyurl.com/ovowm48
If we go that route, that leaves the question what's the best way to bring this in from wikidata? If we need to cache the value (probably?) how should we do cache invalidation?

I vote for brute force approach given the state of technology we have. These are proper names that cannot be automatically translated.

Wikidata is not appropriate because it lacks inflection and proper letter case. The same thing would happen if we translated the project names separately and used a variable No results found on the $1.

{{GRAMMAR}} is not capable enough to be used here.

Trying to construct these from pieces like No results found on the $1 Wikipedia is even worse.

You could cut the messages to half if the first message is No results found on this wiki..

MediaWiki core has 3337 messages, API 1301, skins 101, extension used by Wikimedia 11330. Thousand easy to translate messages are not that big deal to translators. There a risk some of them rush trough them and translate incorrectly, but that is always the case.

When and if these kind of messages become more common, we can look into how to reuse the translations of the project names. That would need the ability for translators to specify different forms and to choose appropriate form for each message. That sounds like overkill for now, though.

Nemo_bis added a subscriber: Nemo_bis.EditedSep 16 2015, 7:07 AM

I don't see a need for such a complex UI for a simple cross-language search. "No results found on this wiki. Showing results in/from Russian." What's wrong with that? Language names are available.

Copying in a discussion from IRC to this task:
14:59:24 ebernhardson: [2015-09-15 21:23:11] moizsyed: turns out what you asked for is very non-trivial...it turns out mediawiki has no way to internationalize project names, so saying something like 'Showing results from German Wikipedia' in russian isn't directly possible

  1. We can use he foreign wiki language when displaying results from other wikis. Users who no no read the other language will also not be able to understand the foreign language articles.
  1. I made a suggestion already few years ago to have another GRAMMAR-like function, the input of which is the English (canonical) project name. It would by default return the input as is, but can be overridden per language/script and thus has to be part of the LanguageZzx classes.

In T112349#1643536, @EBernhardson wrote:

Zeige Ergebnis aus russischen Wikipedia

Correct:
Zeige ErgebnisSE aus DER russischen Wikipedia
("Zeige" should be left out, imho, since it is both optional and ambiguous)

That makes sense but it means we need (number of wikis)*(number of UI languages) strings to have somewhere. As I mentioned, a lot of this data is probably present in wikidata, but we may need to extract it and put it somewhere else (where?).

Yes. But we have already about a dozen or so translations of all, or most, WMF project names in existing interface messages. So what?

Even with a more simple approach like "Showing results in/from Russian." I wonder how capable {{GRAMMAR}} is when it comes to declension.
Czech example: Russian (language) = ruština; in Russian = v ruštině.
Hence "No results found on this wiki. Results in other languages: Russian" or such?

This is hardly the first case this exact problem appeared in MediaWiki. And while solving it perfectly this time (including the declension mentioned above) would be nice to have, going with something simple (again) would be acceptable, I guess.

Cf. e.g. [[MediaWiki:Wminc-infopage-title-p]] (“Wikipedia $1”), [[MediaWiki:Wikibase-aliases-edit-placeholder-language-aware]] (“enter some aliases in $1”), [[MediaWiki:Timedmedia-subtitle-language]] (“$1 ($2) subtitles”), etc., which get translated using some workaround, e.g. “…in language $1” to evade the need for declension of the language name.

e.g. “…in language $1” to evade the need for declension of the language name.

That wouldn't work e.g. for Russian. There's pretty much no way I can think of to make a template that uses nominative language name (i.e. "русский" or "русский язык") that would not sound extremely awkward. The right phrase would be "Результаты поиска на русском языке" or "Результаты поиска из русской Википедии".

That wouldn't work e.g. for Russian. There's pretty much no way I can think of to make a template that uses nominative language name (i.e. "русский" or "русский язык") that would not sound extremely awkward.

Well, my point was just that this “works” (for some value of “works” including ”extremely awkward”) for messages like “Википедия на языке «$1»” ([[MediaWiki:Wminc-infopage-title-p]]). As I said, solving it perfectly would be nice to have, but it is not really easy (and would probably need to be solved more-or-less by brute force, as mentioned above).

EBernhardson added a comment.EditedSep 16 2015, 4:37 PM

David brought up this suggestion on IRC, i think it sidesteps the issue quite gracefully:

Showing results from ru.wikipedia.org
No results found on this wiki.

This is not as much information as an actual project name though.

How about this alternative?

Showing results in: <LANGUAGE1>
No results found in: <LANGUAGE2>

So I think we shouldn't get into grammar because we already have one big can of worms on our hand and adding another dimension to it would make it completely intractable.

So for now I think our main problem to solve is that we need to be able to name certain project - e.g. German Wikipedia - in various languages and we don't have infrastructure to do this now. So as of now this is the big missing part.

Smalyshev added a comment.EditedSep 16 2015, 5:01 PM

@Deskana Just language may be not enough - what if we'd like to also show results from Wiktionary or Wikinews?
Also, while it _kind of_ works in English, e.g. in Russian this form is just awful. And we'll be confusing languages and projects, which I'm not sure is a good idea.

Right now my vote is for:

No results found in current wiki. Below are results from other projects:

== German Wikipedia ==

Der Schmetterling
...

== German Wikinews ==

Ein Schmetterling bewirkt der Hurrikan
...

etc.

David brought up this suggestion on IRC, i think it sidesteps the issue quite gracefully:

That's what MediaWiki core does with interwiki search results, indeed. :) In fact it's not clear to me why you're reinventing an interwiki search interface now (I could not find a task where that's discussed), but ok.

That's what MediaWiki core does with interwiki search results

Where can one see such results? I'm not sure whether we're talking about the same thing...

In fact it's not clear to me why you're reinventing an interwiki search interface now

Well, that's the part we're working on for inter-language search :)

@Nemo_bis were you meaning what Italian wiki does? I'm not sure this is the best way - while it.wikipedia.org is clear enough, I'm not sure every Chinese speaker would identify what zh.wikipedia.org is and the number of people who know what rue.wikipedia.org means is probably very low :)

Of course, we could do that if we find no better solution but I think we should at least try to do better.

Nemo_bis added a comment.EditedSep 16 2015, 7:24 PM

were you meaning what Italian wiki does

The Italian Wikipedia uses MediaWiki core, yes. :) We also have an older screenshot from the English Wikipedia:

(of course that's a bug, but "ru.wikipedia.org results" is still the same and your proposal "results from ru.wikipedia.org" identical from the translators' perspective).

@Nemo_bis I'm not sure the "sister project sidebar" approach is a good way here. Given that it is being used only in one wiki, I think we can not take it as existing standard. Also, it lacks features like snippets and highlighting, which can be reasonable for something like wiktionary, but for inter-language search it hurts the result's usability.

So I think we need a better approach in which the results from multiple wikis can be displayed inline, not just as links in the sidebar.

It was used on all wikis and it's in core, so it IS standard. That you don't like it is another matter.

It is true that I don't like it, but I don't think the problem is in my personal tastes. It just doesn't work the way multi-lingual search should be working - by relegating the results to a sidebar. Especially little sense it makes if the main site returns no results - then all results are in the sidebar and main space is empty. That doesn't look good to me.

And, I don't think that displaying cryptic URLs is an optimal solution. I think it is better to speak to people in their language than in code.

It is true that I don't like it, but I don't think the problem is in my personal tastes. It just doesn't work the way multi-lingual search should be working - by relegating the results to a sidebar. Especially little sense it makes if the main site returns no results - then all results are in the sidebar and main space is empty. That doesn't look good to me.
And, I don't think that displaying cryptic URLs is an optimal solution. I think it is better to speak to people in their language than in code.

Agreed on all counts.

@Deskana Just language may be not enough - what if we'd like to also show results from Wiktionary or Wikinews?
Also, while it _kind of_ works in English, e.g. in Russian this form is just awful. And we'll be confusing languages and projects, which I'm not sure is a good idea.
Right now my vote is for:

No results found in current wiki. Below are results from other projects:
== German Wikipedia ==
Der Schmetterling
...
== German Wikinews ==
Ein Schmetterling bewirkt der Hurrikan
...

etc.

@MSyed Can you work with this and make a mockup? For now we're only displaying results from one other wiki, so it should be quite straightforward.

@Smalyshev @EBernhardson Why can't we just brute force the translation for "No results found for X Wikipedia"? This is a string that will be incredibly useful for us moving forwards.

@Deskana not sure what you mean by "brute force". I agree that string would be useful, but if we want it to look as natural phrase and not as robot glueing words together without regard for grammar, it would have to be translated as a whole, just doing "No results found for $1" would work for English but not e.g. for Russian.

@Deskana not sure what you mean by "brute force". I agree that string would be useful, but if we want it to look as natural phrase and not as robot glueing words together without regard for grammar, it would have to be translated as a whole, just doing "No results found for $1" would work for English but not e.g. for Russian.

Exactly. We could get the whole message translated.

I think we need to have a quick meeting with the i18n team to figure this out. The back and forth is driving me insane.

I think we need to have a quick meeting with the i18n team to figure this out. The back and forth is driving me insane.

I vote for brute force approach given the state of technology we have. These are proper names that cannot be automatically translated.
You could cut the messages to half if the first message is No results found on this wiki..
Thousand easy to translate messages are not that big deal to translators.

What more do you need?

Quick fix requiring only one additional translations, since project names are already translatedi several places, and languages can mostly) be taken from CLDR.

No results found in current wiki. Results from other projects:
[ Note: no "below" - https://www.mediawiki.org/wiki/Localisation#Avoid_references_to_screen_layout_and_positions ]

Wikipedia (localized per twn)

Dutch(localized per CLR)

....

German(localized per CLR)

...

Russian(localized per CLR)

...
...

Wiktionary(localized per twn)

Russian(localized per CLR)

...
...
...
etc.

Quick fix requiring only one additional translations, since project names are already translatedi several places, and languages can mostly) be taken from CLDR.
(snip)

We looked in to that but we unhappy with the unclear visual hierarchy that results.

I think we need to have a quick meeting with the i18n team to figure this out. The back and forth is driving me insane.

! In T112349#1643949, @Nikerabbit wrote:

I vote for brute force approach given the state of technology we have. These are proper names that cannot be automatically translated.
You could cut the messages to half if the first message is No results found on this wiki..
Thousand easy to translate messages are not that big deal to translators.

What more do you need?

I was proposing that to synchronise my team on the problem, as much as anything else. We were brainstorming a lot of ideas but didn't have much of an idea whether they were feasible. It sounds like we're agreed on a course of action though. Thanks for your help.

@Purodha I don't think using just language names is enough. We need project names. Do we have any place where we have project names, in localized form?

We could do double branching like you said - wikipedia/German, etc. but for that we'd need to know that dewiki is "Wikipedia". Is there any place we can know that from?

Change 239444 had a related patch set uploaded (by Smalyshev):
[WIP] Displaying search results for multiple wikis

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

Change 239445 had a related patch set uploaded (by Smalyshev):
[WIP] Displaying search results for multiple wikis

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

We could do double branching like you said - wikipedia/German, etc. but for that we'd need to know that dewiki is "Wikipedia". Is there any place we can know that from?

You could probably manage it with $wgConf->siteFromDB, but be warned there are a lot of ways to go wrong with this. For example, you'll end up with https://wikisource.org being a wikipedia, because it's called "sourceswiki" in the config rather than something sane like "mulwikisource".

This comment was removed by Smalyshev.

Currently proposed form looks like:

I spoke to @Nikerabbit this morning and the decision is that we can put a series of messages in WikimediaMessages that say "Showing results from X Wikipedia. No results found in this wiki". Thanks for helping us figure this out @Nikerabbit and @Amire80!

Nemo_bis removed a subscriber: Nemo_bis.Sep 23 2015, 4:35 PM

We probably will need to rearrange that. Imagine if we wanted to display more than one wiki. Then we need something like:

"No results found in this wiki", then "Showing results from X Wikipedia", then "Showing results from Y Wikipedia" I guess?

We probably will need to rearrange that. Imagine if we wanted to display more than one wiki. Then we need something like:
"No results found in this wiki", then "Showing results from X Wikipedia", then "Showing results from Y Wikipedia" I guess?

This test has been blocked for much longer than was ideal because we couldn't find a solution to all of our problems. So, let's cross that bridge when we come to it. For now, we need to get this test out.

Change 240964 had a related patch set uploaded (by Smalyshev):
Add messages for multiwiki search

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

Smalyshev added a comment.EditedSep 25 2015, 5:18 AM

OK, please see links from https://phabricator.wikimedia.org/T112121 they now show new results. Is it ok? If yes, we'd need to hook up configs to the A/B test setup next and determine which languages we want to enable.

I think the styling due to using <p> tags leaves too much space between the lines. We could join the two messages with <br> inside a single <p> i think. I'm not sure what to do with the 'create this page' link, the spec in the ticket description looks much cleaner without it imo.

@moizsyed: Please review the current UX at suggesty.wmflabs.org and provide some feedback.

Change 241129 had a related patch set uploaded (by Smalyshev):
[WIP] Displaying search results for multiple wikis

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

OK, here's what we've got so far:

https://gerrit.wikimedia.org/r/#/c/239444/ <- patch for CirrusSearch, which refactors additional results as interwiki results. Requires one of the two core patches below.

Now we have two approaches:

  1. Full string ""Showing results from X Wikipedia". Implemented in:

https://gerrit.wikimedia.org/r/#/c/240964/ - WikiMessages (only english messages)
https://gerrit.wikimedia.org/r/#/c/241129/ - core

  1. String combined from "Showing results from [[:$1:Main_Page|$2]]" and "X Wikipedia". May require some creativity in some languages. Implemented in:

https://gerrit.wikimedia.org/r/#/c/241126/ - WikiMessages (only english messages)
https://gerrit.wikimedia.org/r/#/c/239445/ - core

We can choose one of those and then figure out how we can deal with non-English messages.

@Deskana, @MSyed, @Nikerabbit would appreciate comments/reviews/suggestions on the above.

I feel uncomfortable with the brute force approach of creating almost 300 nearly identical messages per project. There are not a lot of languages that will need grammar transformations for language names, and for languages that do need it, they can be programmed quite easily. For an example see https://gerrit.wikimedia.org/r/#/c/172501/ . It's a feature that is needed in other places anyway, e.g. T105588.

I argue that it will take the MediaWiki coders much less time to talk to people who speak languages that need grammar transformations and implement the needed rules than it will take the translators to translate hundreds of messages. Sending people to look for translations of 300 language names to their languages one-by-one when we already have them in Names.php and CLDR seems awfully redundant and error-prone (though I appreciate that a few people would find it educational). It may happen that 300 messages will be so intimidating that to a lot of languages these messages won't be translated at all.

Amir, they need a solution that works now, and brute force is the only practical solution currently.

There are not a lot of languages that will need grammar transformations for language names

I disagree. Please provide evidence.

and for languages that do need it, they can be programmed quite easily.
For an example see https://gerrit.wikimedia.org/r/#/c/172501/
I argue that it will take the MediaWiki coders much less time [...] than it will take the translators to translate hundreds of messages.

I disagree. How many hours did you spent on that patch? And does it work with with all Wikimedia project names? Last time we discussed it didn't due to gender.

We have hardly any coders with time for this task. We have hundreds of translators.

It may happen that 300 messages will be so intimidating that to a lot of languages these messages won't be translated at all.

It may also happen that translators happily work on them as they are easy to translate (less brain, more routine).

Change 240964 merged by Deskana:
Add messages for multiwiki search

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

Smalyshev reassigned this task from Smalyshev to JGirault.Oct 16 2015, 6:09 PM

Change 239445 abandoned by EBernhardson:
[WIP] Displaying search results for multiple wikis

Reason:
Abandoning in favor of https://gerrit.wikimedia.org/r/#/c/241129/

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

@Deskana @EBernhardson @JGirault: What remains to be done on this, if anything?

If it is really on @JGirault's plate, it should move to the UX sprint board. Otherwise it should be reassigned.

Change 241129 merged by jenkins-bot:
Displaying search results for multiple wikis

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

Change 239444 merged by jenkins-bot:
Displaying search results for multiple wikis

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

I reviewed stas's existing code and sent it through. It's not quite beautiful yet but it does work:

http://en.wikipedia.beta.wmflabs.org/w/index.php?title=Special%3ASearch&profile=default&search=nicht+ewig+bestehen&fulltext=Search&cirrusAltLanguage=yes

I'll put together one more patch to make it look a bit closer to moiz's original design. Just goes to show how far engineer and designer designs can be when showing the same thing :)

Change 249064 had a related patch set uploaded (by EBernhardson):
Styling tweaks for inline interwiki search

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

The search above however does not show alternative language version, and no "other wiki" message, is it intentional?

no thats not intentional, it worked the first time around but i changed something...lemme double check

doh, the reason is because thats an actual page in the english wikipedia it found. lemme find another search string to use :)

Change 249064 merged by jenkins-bot:
Styling tweaks for inline interwiki search

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

Change 249912 had a related patch set uploaded (by EBernhardson):
Styling tweaks for inline interwiki search

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

Change 249912 merged by jenkins-bot:
Styling tweaks for inline interwiki search

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

Jay8g added a subscriber: Jay8g.Nov 2 2015, 6:26 AM
Deskana closed this task as Resolved.Dec 3 2015, 5:07 AM
Deskana moved this task from Done to Resolved on the Discovery-Search (Current work) board.