MediaWiki's code for minimumGroupingDigits in numeric formats has an off-by-one error: MediaWiki uses (for example) 2 for polish to indicate that 1000 shouldn't have a grouping separator, but the Unicode CLDR defines this as 1.

I observed that the recommendation api is quite unstable these days. https://es.wikipedia.org/api/rest_v1/data/recommendation/article/creation/translation/en?count=24 This is giving expected results today, but was failing yesterday.

In T259496#6500856, @ngkountas wrote:

In T259496#6498253, @santhosh wrote:

Got it. So can't this be solved if the default UI of tab in our vue UI library follow grey underlines instead of following OOUI style? @ngkountas If we do that, then we don't need customizations right? The tabs we have in desktop dashboard will also follow the grey underline style.

@santhosh I think that there are three important differences between our current tab UI component and the desired one (at least for this case):

Got it. So can't this be solved if the default UI of tab in our vue UI library follow grey underlines instead of following OOUI style? @ngkountas If we do that, then we don't need customizations right? The tabs we have in desktop dashboard will also follow the grey underline style.

@Pginer-WMF About the style for this tabs, do you see this as a tab UI component pattern or a new UI pattern? In dashboard, we have similar tabs(suggestions, published, in draft). Do you think those tabs and this should use different styling and UX? Asking this because, the Vue component need to be designed for that pattern. The way @ngkountas attempted to solve this is by reimplementing the tab component just for this screen. Is there a logic behind using #222 for highlighting pattern deviating from OOUI style

I propose adding the following too:

Error while reading config file: Error: ENOENT: no such file or directory, open '/opt/cxserver/config.yaml'

Thanks @Jdlrobson!. I will try to take it forward.

In T243495#6455216, @Jdlrobson wrote:

Definitely can help with that. When do you need to know by?

@Jdlrobson Can you please guide us with this approach? I am not familiar with skins system. If we create a new skin, wouldn't it be globally available? Can it be used for just a special page? Can you give some pointers on where to start?

In T260236#6380074, @sbassett wrote:

^ to follow up: I think we'd be looking for something a bit beyond the basic installation instructions, whether that's a docker or similar that works out of the box with minimal effort and no missing pieces (elevated rights, credentials, dependencies, etc). If the installation instructions can accommodate this (have not tried them yet), that's fine.

Screencast of cypress integration:

In my opinion, this is mostly about design vocabulary we want to follow. If we want a consistent design pattern where icons(in its purpose defined by design style guide) are always at the beginning of a component, there is no question of icons appearing elsewhere in the component. So icon not only get its position, but its meaning and purpose. Same for indicators.

In T241589#6402210, @Jpita wrote:

I cannot start a translation in https://sx.wmflabs.org/

After considering the complications, I changed my mind. Rather than developing a small hack router, it would be better to use vue-router itself. https://gerrit.wikimedia.org/r/621679 illustrates this.

In T254780#6395844, @kostajh wrote:

Thanks @santhosh!

nodejs and npm - if possible latest LTS versions.

Personally I lean towards providing instructions and tooling to use wikimedia/fresh. Consistency with CI would be a major advantage of going that route. I'm interested to hear what others think.

I created this page: https://www.mediawiki.org/wiki/MediaWiki-Docker/Configuration_recipes/Customize_base_image

One way to do this is modifying the mediawiki service in docker-compose.override.yaml as follows:

I am working on this. With https://www.mediawiki.org/wiki/Docker it is not much difficult to get Content Translation up and runnig with its database, cxserver instance. I will document it in detail at https://www.mediawiki.org/wiki/MediaWiki-Docker/Extension/ContentTranslation

Changed related to this ticket caused a bug in the Wikidata linking in ContentTranslation - T249458: ContentTranslation is not adding pages sitelinks to wikidata

Content translations, wikidata linking code depends the RL module mw.config.values.wbRepo. So please let us know the migration strategy too.

I see that mw.hook( 'wikipage.content' ).fire( $( '#mw-content-text' ) ); for Use this hook if you need to enhance or modify parts of a wiki page.. But for CX, the UI has nothing common with any Special page or content page by product design. We reimplemented the personal toolbar too. There is no side bar. Since CX was launched in 2014, we have seen some reports that says it broke some gadgets and we talked to the authors and fixed(most of them were using document.getElementById and assuming the existance of sidebar). That means, so far we were in the assumption that there is no such contracts to have an element with id mw-content-text.

The issue about section title heights(shown in second screenshot) is not fixed yet

https://gerrit.wikimedia.org/r/618700 is not merged yet

@Jpita You may just verify the above result and move

Example:
https://cxserver.wikimedia.org/v2/suggest/sections/Sitar/en/ml

{
  "sections": {
    "sourceLanguage": "en",
    "sourceTitle": "Sitar",
    "targetLanguage": "ml",
    "targetTitle": "സിത്താർ",
    "sourceSections": [
      "Etymology",
      "History",
      "General layout",
      "Construction styles",
      "Tuning",
      "Playing",
      "World music influence",
      "See also",
      "References",
      "External links"
    ],
    "targetSections": [
      "പ്രമുഖർ",
      "അവലംബം"
    ],
    "present": {
      "References": "അവലംബം"
    },
    "missing": {
      "Etymology": "പേരിന്റെ ഉത്ഭവം",
      "History": "ചരിത്രം",
      "Playing": "വായിക്കുന്ന രീതി",
      "See also": "ഇതും കാണുക",
      "External links": "പുറത്തേക്കുള്ള കണ്ണികൾ"
    }
  }
}

Set to high priority since we don't want to see the publishing feature failing at any cost.

I think we need to go with a vuex based approach where we store the app state and step in a store module. We need store module 'app' for that. It will have the current step, and we can have the main content area rendering based on that step. If mobile render it as full screen dialog. Mutating the step can change the history hash from store. This will avoid the need for 25K vuerouter library too. The app vuex store module has more use beyond this, such as saving and restoring last selected language from localstorage etc(but that is futuristic). he language selectors can be still dialogs(full screen or not).

Different scripts has different line height requirements. So, shouldn't we consider defining them per script or language basis? Please take a look at bo.wikipedia.org - that script has 3 level vertical stacking.

The language team wrote one such component(Demo, Code). Feel free to refer/copy/adapt

Videos from current version:

No. just FYI now. Marking as resolved

I see that the api is now returning results. Closing this. But I understand that the section suggestions in CX need to be aware that the suggestions are not 100% guaranteed for a given language pairs due to the issues we observed and chances that it can repeat in future.

Update: We have not looked into this lately. Partly due to less complaints regarding this issue and hence its relatively low priority.

Update: We have not looked into this lately. Partly due to less complaints regarding this issue and hence its relatively low priority.

This seems to a minor regression resulted from https://gerrit.wikimedia.org/r/c/mediawiki/extensions/ContentTranslation/+/596635

In T199004#6262993, @Niedzielski wrote:

Docs outline both approaches. WVUI will use runtime-only and will use build step.

In T199004#6253258, @JoeWalsh wrote:

@dcipoletti will be the point of contact for the specific implementation proposal moving forward. Requirements from stakeholders and his team's Vue.js work on search will inform the proposal.

In T247499#6255995, @Jpita wrote:

@santhosh Do I need to do something here?

The components are illustrated in storybook: https://people.wikimedia.org/~santhosh/storybook/

Moving this to QA since basic components are developed. We will have specific ticket for enhancements and new features of this UI library.

I created two follow up tickets based on Pau's comments:

Closing this since we did the workaround of adding /*@nomin*/

Since adjusting threshold per language pair will require more development work, we need to plan it. For now, removing from our focus sprint.