In T343062: Add a different completeness status design for 100% complete translations Quiddity asks to have visual separation for complete and almost complete.

Copying/Updating my merged task Description:

• As a reader (& potential translator),
  • Or, as someone who is sending a translatable MassMessage,
• I want to be able to glance at the <languages> bar and determine if a language is fully translated or only partially translated. This is currently impossible, and I have to mouseover each one, as 75-100% are all the same.

In T329046#9068230, @Quiddity wrote:

Copying/Updating my merged task Description:

• As a reader (& potential translator),
  • Or, as someone who is sending a translatable MassMessage,
• I want to be able to glance at the <languages> bar and determine if a language is fully translated or only partially translated. This is currently impossible, and I have to mouseover each one, as 75-100% are all the same.

Thanks for the input. In the proposals different levels were considered:

• (Almost or) Not translated. Nothing to consume. Please start translating.
• Lightly translated. Hard to consume. Contributions very welcome.
• Mostly translated. Can be consumed. Contributions still welcomed to complete it.
• (Almost or) fully translated. Ready to consume.

Your input would suggest to make the most complete level to be more strict ("fully translated", that is, 100% complete) as opposed to being bore flexible ("almost/fully completed", which could be 90-100% complete). Does that make sense to you or were you thinking on different ranges to be more useful?

@Pginer-WMF Yup, exactly. I think a distinct "100%" indicator would make it clearest to potential translators if there is anything missing, and thus give impetus to complete a partially-done page. Otherwise, a page with 10 sections but a single missing translation for a newly added "== Updates ==" section might be overlooked, because the translator glanced at the header-bar and saw the 'almost complete' indicator but interpreted the fully-filled-circle as indicating 'complete'.

@Wangombe, based on the above feedback we could go initially with the "4 levels (asymmetrical)" approach with the following ranges (assuming the percentages don' have decimals, or rounding is used if they internally do):

• 0-14%
• 15-69%
• 70-99%
• 100%

For the 3rd level I adjusted the representation to increase a bit the white portion to be more distinguishable at smaller sizes (using a white portion of 100° instead of 90°.
An example in a more realistic scenario:

I wonder if the color of the circles might be considered/tested a bit, or details shared about the reasons behind the change to blue?
I.e. I'd be curious to see the new designs but using green instead of blue.
Context: I find the current green icons are helpfully distinct from the blue text, and this makes it easy to skim the icons -- this is useful for someone like me where that (completion-status) is usually my main interest, versus trying to find a specific language.
It might also be helpful for folks who are trying to find a specific language, as the green might provide clearer separation of words. Especially in a page with many dozens of translations, such as Meta-wiki's Main Page or Meta:Babylon.

Change 957285 had a related patch set uploaded (by Wangombe; author: Wangombe):

[mediawiki/extensions/Translate@master] Improve page translation progress indicators

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

Here are some results of the implementation.

0-14%	15-69%	77-99%	100%

In T329046#9245248, @Wangombe wrote:

Here are some results of the implementation.

0-14%	15-69%	77-99%	100%

Good progress! Some quick comments about minor aspects to adjust:

The symbol for the 0-14% range:

• The Base30 (#72777D) from the color palette should be used instead of blue to better communicate the notion of incompleteness.
• The current implementation shows a small segment filled. The proposal for this range is to show only the border of the circle without any completed segment. This simplifies the shapes for quick visual scanning.

The rest of the symbols:

• The Accent50 (#3366CC) from the color palette should be used for the blue color elements.

For the 15-69% range:

• The circle should be 50% filled. Currently it seems it is a bit less (maybe that's a pixel alignment issue)

For the 77-99% range:

• The circle should be 70% filled. Currently the filled area is larger getting visually too close to the completed state.

In T329046#9248912, @Pginer-WMF wrote:

For the 15-69% range:

• The circle should be 50% filled. Currently it seems it is a bit less (maybe that's a pixel alignment issue)

Depending on the screen resolution of the user, the fill might appear with a jagged edge. I tested this by increasing and decreasing the zoom percentage of the test page.

In T329046#9161662, @Quiddity wrote:

I wonder if the color of the circles might be considered/tested a bit, or details shared about the reasons behind the change to blue?
I.e. I'd be curious to see the new designs but using green instead of blue.
Context: I find the current green icons are helpfully distinct from the blue text, and this makes it easy to skim the icons -- this is useful for someone like me where that (completion-status) is usually my main interest, versus trying to find a specific language.
It might also be helpful for folks who are trying to find a specific language, as the green might provide clearer separation of words. Especially in a page with many dozens of translations, such as Meta-wiki's Main Page or Meta:Babylon.

The idea was to start simple by using a simple progress indicator to avoid additional noise. A list of languages in this context can result in significant repetition, and we may need to be careful about how many signals we use and how prominent those are.

Trying som examples based on real data will be helpful to understand whether we need to increase the prominence of this indicator.

In T329046#9253328, @Wangombe wrote:

In T329046#9248912, @Pginer-WMF wrote:

For the 15-69% range:

• The circle should be 50% filled. Currently it seems it is a bit less (maybe that's a pixel alignment issue)

Depending on the screen resolution of the user, the fill might appear with a jagged edge. I tested this by increasing and decreasing the zoom percentage of the test page.

Thanks for the clarification.
I also noticed that the image incorporates most of the provided feedback. One aspect I noticed is that the the symbol for the 0-14% range seems to be using a filled grey circle. The intention was to have a border-only circle in grey.

In T329046#9161662, @Quiddity wrote:

Context: I find the current green icons are helpfully distinct from the blue text, and this makes it easy to skim the icons -- this is useful for someone like me where that (completion-status) is usually my main interest, versus trying to find a specific language.

Since the new version is CSS-only, you can always override the colors in your common.css/global.css file.

LTR	RTL

Here are the results. I believe all the cases have been captured with the current implementation.

I believe you, but I’d like to note that no RTL translation pages are visible on the screenshot, so only two out of four cases (LTR-on-LTR and LTR-on-RTL) are tested.

Few more screenshots from Firefox (118.0.2 (64-bit)) on Arch Linux:

Case 1: RTL with an RTL language translation:

Case 2: Language bar in the sideabar with RTL:

Case 3: Language bar in the sidebar with LTR:

There are also known issues with anti-aliasing for gradients on Chromium based and Firefox browser.

I also noticed that the unfilled part is on the left both using Hebrew and English UI. It should probably be on opposite sides.

In T329046#9293810, @Tacsipacsi wrote:

I also noticed that the unfilled part is on the left both using Hebrew and English UI. It should probably be on opposite sides.

I got an opinion from a native speaker that it's okay to keep it as it is. It's just N=1 but I'd go with the current implementation for now.

Okay, let’s go with this then (unless someone raises concerns before the patch is merged). It can always be reconsidered later, should concerns arise.

Change 957285 merged by jenkins-bot:

[mediawiki/extensions/Translate@master] Improve page translation progress indicators

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

Change 972932 had a related patch set uploaded (by Wangombe; author: Wangombe):

[mediawiki/extensions/Translate@master] Remove unused resource, update .mw-pt-progress--low

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

Change 972932 merged by jenkins-bot:

[mediawiki/extensions/Translate@master] Remove unused resource, update .mw-pt-progress--low

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

After TranslateWiki deployment, the icons appear as below. This link showcases the changes implemented from this ticket

I happened to open the page in a browser with NoScript, and it doesn’t look great. ☹️ The indicators of languages whose names don’t fit in one line are on the far right (actually in the overlay scrollbar area, so I don’t see the icons while scrolling). While I didn’t try using the language selector on a translatable page using Vector 2022 and disabled JavaScript before, so I don’t know how it looked like, I do remember that on Timeless, all icons were on the far right, and now aren’t, so probably the Vector 2022 inconsistency is also a regression caused by this redesign.

Adding

.mw-pt-progress > a {
	flex-grow: 1;
}

fixes Timeless and makes no-JS Timeless more consistent (all indicators below the scrollbar – adding some padding/margin could fix this), but I didn’t test it on other skins or the output of <languages/>.

There's some feedback at https://www.mediawiki.org/wiki/Topic:Xtiir7e6iubumeqq asking for the CSS needed to replace the new styling with something less prominent.

In T329046#9339445, @Quiddity wrote:

There's some feedback at https://www.mediawiki.org/wiki/Topic:Xtiir7e6iubumeqq asking for the CSS needed to replace the new styling with something less prominent.

Replied there.

Change 975804 had a related patch set uploaded (by Abijeet Patro; author: Abijeet Patro):

[mediawiki/extensions/Translate@master] Tweak CSS for page translation progress indicator

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

Some test with the latest patch:

Normal on Vector:

Vector 2022 with JS disabled:

Vector 2022 with VectorLanguageInHeader as false and PageTranslationLanguageList = 'sidebar-only'.

With the language bar

Timeless: language bar

Timeless: sidebar

Change 975804 merged by jenkins-bot:

[mediawiki/extensions/Translate@master] Tweak CSS for page translation progress indicator

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

Here's a screenshot from https://translatewiki.net/wiki/Help_us with the latest changes deployed:

Vector 2022 with JS enabled:

Vector 2022 with JS disabled:

Vector 2022 with JS disabled and an rtl interface language:

Timeless with an rtl language:

Leaving the task open for any additional feedback from users.

Thanks for the fix! The margin of the non-ULS language switcher is still odd, but it’s probably okay for a fallback solution. (And even if it isn’t, it looks like something to fix in Vector, not in Translate.)

In T329046#9355357, @abi_ wrote:

Here's a screenshot from https://translatewiki.net/wiki/Help_us with the latest changes deployed...

Thanks for sharing the examples. I noticed some aspects that we may consider adjusting:

Shape and size of the circles

Looking at the circles, they are not always perfectly round. I inspected the size and found that the height and the width are not of the same value when computed in pixels:

The issue seems to be related with the use of "em" units. When I replaced them with "rem" instead, the circle appears with a more round shape.

In addition, the circles appear a bit large with respect to the text. Using 0.5rem as the size makes their size more harmonious with the text.

Placement in the language selector

Currently the indicators are placed after the language labels in the language selector. The language selector has space reserved for this kind of indicators before the labels. This is used on Wikipedia for signals such as featured/good article.

Spec showing the placement of indicators	Example from Wikipedia

Conclusion

With the above changes the the language selector would look like this:

If the adjustments are not trivial, we can move the proposal into a separate ticket.

In T329046#9356277, @Pginer-WMF wrote:

The issue seems to be related with the use of "em" units. When I replaced them with "rem" instead, the circle appears with a more round shape.

In addition, the circles appear a bit large with respect to the text. Using 0.5rem as the size makes their size more harmonious with the text.

Using rems would worsen the circle-to-text-ratio situation: the em specifies the size in terms of font size of the current element, while rem specifies it in terms of the font size of the HTML element. The ratio between the two varies across skins (em calculated on the <a> elements of the interlanguage links):

• Vector 2010: 1em = 0.75rem
• Monobook: 1em ≈ 0.86rem (75%×127%×95%×95%)
• Vector 2022 (ULS or fallback language selector): 1em = 0.875rem
• Timeless: 1em = 0.9025rem (95%×95%)

The rem value that looks good on Vector 2010, is way too small on Timeless, and conversely, a value appropriate for Timeless is huge on Vector 2010.

Currently the indicators are placed after the language labels in the language selector. The language selector has space reserved for this kind of indicators before the labels. This is used on Wikipedia for signals such as featured/good article.

I’ve thought about this, but I thought that they would be too prominent if placed before the links (only a small portion of languages have featured/good articles on a given subject, while all translations have progress levels, which results in much more indicators). However, looking at your mockup, it isn’t that bad, so it may be worth implementing it and evaluating it on other skins as well.

Thanks for the feedback, @Tacsipacsi.

Using rems would worsen the circle-to-text-ratio situation...

Good points. Maybe the change of unit is not the way to go. I was surprised to see that an element with the same width and height expressed in Ems was rendered with different sizes. Given that Ems can be problematic in some contexts, I tried the "similar" Rem unit. But I'd be ok with any technical solution that make the circles a bit rounder.

I’ve thought about this, but I thought that they would be too prominent if placed before the links (only a small portion of languages have featured/good articles on a given subject, while all translations have progress levels, which results in much more indicators). However, looking at your mockup, it isn’t that bad, so it may be worth implementing it and evaluating it on other skins as well.

Having the circles closer to the labels helps to perceive them more sa a unit, making the perception of being a lower number of elements (i.e., looking simpler). For cases where the language selector has many languages, andl multiple columns are used, placing the indicators after the label in the first column would make them closer to the labels of the second column, creating potential confusion too.

Change 979028 had a related patch set uploaded (by Abijeet Patro; author: Abijeet Patro):

[mediawiki/extensions/Translate@master] Translation progress indicators: Do not shrink the circles

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

I've figured out the reason why the circles were not perfectly round, and submitted a patch to fix it. Screenshot from my local:

See: https://stackoverflow.com/a/37818560 for more details.

Other issue I noticed is that the space between red links and blue links is inconsistent:

This seems to be caused by the margin-inline-end that has no equivalent for the red languages.

Change 979028 merged by jenkins-bot:

[mediawiki/extensions/Translate@master] Translation progress indicators: Do not shrink the circles

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

I have filed the remaining TODOs as subtasks so that we can proceed to close this one.