We may not need model hosting if we use static embdding. I did an evaluation here https://phabricator.wikimedia.org/T403146#12420146 Static embedding as able to match the results without any ML library and runs extremely fast on CPUs. Will update this ticket based on the decisions

I did an evaluation of the quality of current section alignment. I used the human curated, published CX Corpus and extracted all section title alignemnts(Golden data). Then for those article titles and language pairs, used currect CX approach to find alignement. This results were evaluated against golden data. I got F1 score as 0.763 for 7 languages used.

To confirm whether current Qwen3-Embedding-0.6B) can help, I did an objective analyis. For high resource languages like Spanish, it gives comparable results, but for mid to low resource languages, it is a failure.

To answer whether the published articles by CX got edits from other contributors, I added a dashboard at https://cxstats.toolforge.org/article-growth/all

Not a fix. just an analysis:

https://gerrit.wikimedia.org/r/1341080 is the patch that tries to do regex and grab the definition from the transclusion param values. But I am not in favor of such fragile fixes. When VE start to recognize the template values as wikitext and offer visual editing experience, we can revisit it

Since v2 (ULSv2,wgULSLanguageSelectorV2Enabled) is used in the code already, we just need to make it consistant in module names and file names

Given that the paragraph is going to be small number of sentences. Say 3 or 4 sentences, can't we do a very relaxed approximate search and pick a most likely paragraph? This wont require any models. Roughly:

The root cause was in cxserver. Not in Content Translation or VisualEditor.

pt, pt_br, pt_pt is just one case, there are a few more locales where the CLDR fallback chain differs from MW chain.

Hi, I submitted a new merge request https://gitlab.wikimedia.org/repos/releng/blubber/-/merge_requests/176
I squashed commits by @gkyziridis, rebased and worked on top of that.

Tech News description:

Content Translation now supports dark mode, as requested by communit wishlist.

After I fixed it, the code became complex and hard to read. So I rewrote the approach in latest patch(PS 4) with a simplified method while keeping all tests as such. Results:

I debugged it and the extra space before the "." was causing our "fullstop followed by reference" checks failing. I added additional unit tests from your example and fixed it.

Root cause:
VE core refactored ve.dm.Converter into a facade that delegates DM→DOM conversion to a separate internal ve.dm.DomFromModelConverter instance (this.domFromModelConverter). (change: https://github.com/wikimedia/VisualEditor/commit/1e0c83ecbf97b307b52a4fe8a215f4a4b6c5d643 dated July 9 2025)

Hi @gkyziridis, I am planning to take up this. Hope you dont mind. I will work on top of your commits.

Thanks for testing

Missing References is a well known CX issue where we are not able to adapt it from source to target due to two reasons: (a) target template not available (b) Machine translation on html format could not find a place to put that reference. There are multiple layers of fallbacks like trying to move to end. It is a huge set of issues as we can see in the epic ticket T200786: Better support for References in Content Translation (epic). This ticket focuses only repositioning the survived references.

As of July 2026, the issue still exists for other providers like Google, but doesn't occur for MinT MT provider.

Yandex is no longer a service in cxserver

I am closing this. From my reading and experiments, it is still a work in progress experiment and did not stabilize for our usecase.

The section title databse approach is no longer working for long tail of languages. Additionally, they also adds many wrong mappings. We are seeing the limit of the algorithm .Alternative approaches like embedding based similarity is being explored.

Screenshots:

Thanks. This is resolved

There is a common usecase: Given an article title, getting a thumbnail image of that article with preferred size. But if I understand correctly, this ticket mostly framed as given an image title, get its requested size variants. But knowing the image title require getting article info first (I am thinking from the POV of a downstream API user to display an image along with article title).
Would it make sense to change the proposed spec to accept article title instead of image title? Or is it clearly out of scope?

I saw that T393301: Integrating real time edit checks in Visual Editor using ML implemented this concept in VE.

This is a common issue with IMEs composition. Samrt Input method engines like Samsung autocomple does not give the text to textbox till it completes its autocomplete process. It is on hold till the user choose one. Then only the input element see the text. But the user see it before and get confused. Technically, these events are called IME composition and commit
Basically, we end up with a native autocomplete and web apps autocomplete. Experimenting by adding autocomplete="off" may be a good idea to start with.

In T427379#11962165, @Tacsipacsi wrote:

With the implementation being in Rust, it needs to be added as a microservice (if the setup supports that – WMF production certainly does, but I’m not sure about translatewiki.net, let alone third-party wikis), it cannot be added to the extension directly. Is there any reason you wrote this in Rust rather than in PHP?

I would like to move some of the python services(example) to uv based workflows. @gkyziridis I see that the merge request is not closed yet. Are you planning to work on this?

I found https://github.com/wikimedia/oojs-ui/commit/65fb50d22dc1187f4fe70c3c530dfa7ed1d3e328 as the commit that introduced fixed width. (Ref T411252)

https://translation.googleapis.com/ URL is 404.

Closing this 10 years later . Currently we have https://superset.wmcloud.org/superset/dashboard/p/X61GbQpZ5Rb/ and https://cxstats.toolforge.org/ both shows all of the requested information

I tried both examples and I dont see the error happening. Since this is about 8 years old ticket, I am closing it

Thanks!

Also observed in https://cxserver.wikimedia.org/v2/page/en/fr/Charles-Valentin%20Alkan

Reopening as I see this issue is still happening. Root cause may be different though

Cloud VPS may be an option

Text chunking strategy for TTS usecase is typically sentences for faster first response, proper pauses and intonation at the end of each statement. if you cache the audio by hash(sentence)->audio chunk, we can have higher cache hit ratio in the case of new article revisions.

We already have a multilingual embedding model deployed on Liftwing (Qwen3-Embedding-0.6B) which has longer context and pretty good performance. Could you use that one instead for this use case as well?