Page MenuHomePhabricator

Glosses: display the language name also in edit mode
Closed, ResolvedPublic5 Story Points

Description

Problem:
The language of a Gloss of a Sense is displayed with its name of the language in the interface language when viewing a Sense. When editing the language code is required. This is confusing.

Solution:
Show the language name and code like it is done for editing of monolingual text values.

Screenshots/mockups:
How it looks for monolingual text:

BDD
GIVEN a Sense with a Gloss
AND I am in edit mode for that Sense
WHEN entering a new Gloss or editing an existing one
THEN the selector shows the language name in the interface language and the language code in brackets behind it

Acceptance criteria:

  • language name and language code is accepted for input
  • language name and language code are shown in the selector

Event Timeline

Lydia_Pintscher triaged this task as Normal priority.Nov 20 2018, 11:00 AM
Lydia_Pintscher created this task.
Lydia_Pintscher moved this task from Incoming to Ready to estimate on the Wikidata-Campsite board.
Addshore set the point value for this task to 5.Nov 20 2018, 2:12 PM
Addshore moved this task from incoming to in progress on the Wikidata board.Nov 21 2018, 8:19 AM

extensions/Wikibase/view/lib/wikibase-data-values-value-view/lib/jquery.ui/jquery.ui.languagesuggester.js is what we want to use

Change 477790 had a related patch set uploaded (by Tarrow; owner: Tarrow):
[mediawiki/extensions/WikibaseLexeme@master] WIP Introduce LanguageSelectorWrapper Vue Widget

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

As you can see in https://gerrit.wikimedia.org/r/c/mediawiki/extensions/WikibaseLexeme/+/477790 attempting to complete this task by just wrapping the same widget we use for monolingual text had a few issues.

Attempting to follow the pattern for ItemSelectorWrapper which is used by LanguageAndLexicalCategoryWidget resulted in a working selector.

Specifically it is rather tricky to test well.

Indeed it appears that ItemSelectorWrapper isn't actually tested (other than by ruby browsertests) because the templates used in the tests are out of sync with the templates shipped by PHP (see: T198455).

Tarrow removed Tarrow as the assignee of this task.Jan 3 2019, 11:10 AM
Tarrow added a subscriber: Tarrow.

It does not appear that deploying this patch without parser cache invalidation will cause cause frontend JS breakages.

I tested this locally by:

  • un-setting my value of $wgParserCacheType = CACHE_NONE.
  • so $wgParserCacheType defaults to CACHE_ANYTHING
  • loading current master
  • loading a lexeme page with a sense
  • updating to https://phabricator.wikimedia.org/rEWLEeb5a1879371b6c77d13e77a1e56f4b3411874082
  • reloading the page and confirming that it still has the old behaviour and no errors in the console
  • purging the cache with action=purge and now confirming it has the new functionality

I believe this is because the frontend JS remains backwards compatible with the old pages in the cache because the new widget simply isn't loaded and a plain <input> is still there.

Change 477790 merged by jenkins-bot:
[mediawiki/extensions/WikibaseLexeme@master] Introduce LanguageSelectorWrapper Vue Widget

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