BTW, I won’t be so concerned with wrong punctuation, since most of the time punctuation can be converted. However, this can’t be said of the comma and quotation marks – I’d be a lot more concerned about any MT engine that gets commas and quotation marks wrong (this also applies to zh-TW and zh-HK, or any zh-Hant in general for that matter, if zh is ever going to be split).

@Pginer-WMF I have done some sloppy work on “translating” zh-TW to yue-HK using string substitution (you can probably find it on github, it’s there; it’s very project-specific). For sure a proper ML network would perform much better, but I’d be inclined to say it’s still going to be a very inexact art. This has to do with the difficulty in parsing Chinese.

@Pginer-WMF – At this point I’d suggest than not only should MT be disabled, both data sets should be thrown out as invalid data, and any data in the MT should be nuked because they have been poisoned by the two invalid data sets. If WMF still believe MT had any merit for yue, everything should be restarted from scratch.

@Pginer-WMF – As to “helping the MT”. I’m really sorry if you didn’t understand how much of a waste of time it is even though I mentioned my experience. It’s just not practical to fix any MT longer than a stub. Also, in case you’re not aware of this, we are literally working out basic things like orthography (many other non-Mandarin Chinese languages are doing the same thing). There is a reason we consider ourselves a small language community. The MT will not learn anything from user input even if our editors are superhuman.

@Pginer-WMF: This shows the problem is even worse than what I expected: Even Microsoft has no clue as to what Cantonese is. @H78c67c is absolutely correct. Neither yue-guoyu nor yue-shumianyu are Cantonese; they are not even variants.

FWIW, many translation agencies (I’d say close to if not actually 100% of them) assume Cantonese = zh-HK, and yes, they call zh-HK “Cantonese” (yue). This might explain why a supposedly yue dataset would be 0% Cantonese.

For the record, I managed to fix a section translation in the other direction (en>yue). It was just a 137-word stub and I must have spent like half an hour comparative-editing it, and at the end about 30% was wrong. And I’m not talking about the kind of mistakes that you can look at it and see right away; I’m talking about the kind of mistakes that you have to read and reread the original multiple times to check if anything has been translated out of context or in the wrong sense.

As a user, I’d just like to comment that on Android (and other UI’s that have search) search rarely truly helps. (On Android I often can’t find things any more, even with search.)

In T330613#8647798, @Aklapper wrote:

Hi @Al12si, thanks for taking the time to report this! Please always include full specific links, and a clear list of steps to reproduce - when exactly does some translation popup appear and what does it say?

This is happening also with the Monobook and Timeless skins. It looks like the only skin that isn’t affected is MinervaNeue (mobile).

@Pginer-WMF I think something needs to be made clear, and for the record this should ideally go into some kind of WMF policy document because it seems even translation agencies and large unversity presses (I mean like OUP) don’t understand how “Chinese” (the macrolanguage) works.

In T304865#8629365, @KartikMistry wrote:

In T304865#8627370, @H78c67c wrote:

This unexpected change is attracting some negative attention and reaction at https://zh-yue.wikipedia.org/wiki/Wikipedia:城市論壇_(技術)#點解加咗個鼓勵人翻譯到中文維基嘅功能？

Please see: https://zh-yue.wikipedia.org/wiki/Wikipedia:%E5%9F%8E%E5%B8%82%E8%AB%96%E5%A3%87_(%E6%8A%80%E8%A1%93)/%E6%AD%B8%E6%AA%94/2022%E5%B9%B46%E6%9C%88#Enabling_Content_and_Section_translation_tool_in_Cantonese_Wikipedia

This would not be an enhancement. I have worked at a newspaper publisheer before and I know very well the pitfalls of any such language converters; the last thing I’d like to see is to introduce all the typos typical of automatic language conversion onto my now-home wiki.

In T329535#8626230, @Quiddity wrote:

Yup, the more simple and short, the better (for ease of translators, and ESL folks, and non-tech folks). I've summarized it as:

In T11436#8616765, @Aklapper wrote:

@Al12si Please feel welcome to contribute patches which fix problems, provide clear steps to reproduce, links, and explain who we is. Thanks a lot!

This is not a feature request; this is an outright bug. It’s 2023 already and all mainstream browsers have implemented writing-mode: tb, but when we try to use it we’re greeted with “Invalid or unsupported value for property writing-mode” and our CSS doesn’t even save. This is not an acceptable state of things.

BTW I’ve partially reverted the title of this ticket because it was reworded incorrectly. This is about the “message documentation” (annotation subpages, /qqq; “message documentation” is how this is labelled in the UI), not about translated messages (target strings). Since I’m still trying to reproduce it the title might still be wrong but this is at least more accurate.

@Nikerabbit - What I wrote in my original comment was the complete error message. It was just “Error saving message documentation”.

In T325615#8480611, @Aklapper wrote:

(What is "CAT"?)

New data point: I was updating the page for the sound logo contest so the CAT was showing source text differences for the segment. I was typing a wikilink (therefore it took more than 3 seconds) and suddenly the segment disappeared.

BTW, the actual API message that accompanies some of the strings I saw is completely meaningless. All we see is something like API strings should not be translated (note that it does not say should not be translated unless you know the API; it says they should never be translated), and since the string in question doesn’t look like it has to do with any sort of API, and we’re clearly presented with a string that should be translated, the whole message just looks like a random useless message put there by mistake. This is how unclear these templates are.

PPS: You are making a lot of unfounded assumptions here, and you clearly did not read my initial comment. I clearly wrote that I know about PO files so it’s quite clear that I’ve done software translation before.

PS: All this is not new information; it’s all in the initial comment.

And let me reiterate: There was ZERO context in that string, and therefore the string is not translatable. I have seen what a string with a link to context looks like; that string that triggered this “question” did not have that kind of link.

In T325126#8468762, @Amire80 wrote:

It says: "See API:Main page at MediaWiki.org for general information.", where API:Main page is a hyperlink. Have you read it?

PPS: From our POV you could even say we clicked a link that would take us to translatewiki support, but we end up here instead. That’s why I said initially that “I don’t know why I’m being taken to Phabricator.” If you think the message is very clear, you are wrong.

PS: I don’t know why ApiHelp is even being mentioned here. No one (from the translator’s POV) knows what it means, and “technical” is an undefined term (from our POV).

Or, rather, it *was* a question, in that we are essentially told to come here to ask a question *about that string*, or at least how that message is perceived. If this is not the intention that template should be fixed so it communicates the correct message.

This is not a question, and this is not about the Apihelp template (sorry for using Wikipedia jargon here). This is about the inappropriateness and unhelpfulness of this message while a new translatewiki translator is being “trained/tested” (sorry for being ambiguous because that site is being very ambiguous of what we’re seeing).

I tried to skip a few strings and encountered another of these. It has the word “add”, which is untranslatable unless we know precise context; I’ve alluded to this problem (the exact same word) when discussing Tech News issue 2022/50 on Meta (https://meta.wikimedia.org/wiki/Talk:Tech/News/2022/50).

BTW, the UI of zh-classical isn’t properly translated (it’s in written Mandarin, not classical Chinese); had it been properly translated the label for Reply is likely just a single character (likely just 覆)

In T323537#8464500, @matmarex wrote:

It was a combination of both, but I don't remember us talking about Korean language in particular. We'd be happy to change it as well if there's support for this among the Korean speakers.

Just curious, but why not Korean too? Korean 답변 (hanja 答辯 according to Wikipedia search) is also just 2 characters. Was the list a result of a systematic review, or was it created through user feedback only?

This is last week’s Tech News:

This is continuing to happen this week. Some of these failures are pretty inexplicable. For example, my translation for “Recent changes” is still not showing as a “suggestion” even though it’s recent AND has been used for at least half a dozen times already. Meanwhile, ancient translations that have been been used for only 2 times are showing.

By the way, I’m doing this week’s Tech News right now and there are like at least 3–4 strings (which I’ve been using for a few weeks, basically since I’ve been doing this) that have no valid suggestions at all (i.e., either no suggestions or only 1 suggestion from way back before I started). Something is very wrong with the matching algorithm.

If this is only for 1600px and above, I have a question: Why?

Not to mention this is also an accessibility issue. Not everyone types through a keyboard. Any response-time-based assumptions are ableist.

I would like to comment that non-Latin languages exist. In CJK languages input is typed via an IME. Even if we typed continuously (from our POV) the system wouldn’t see input as being continuous. This is essentially a form of Euro-centric discrimination.

I just want to add that this is a pretty serious problem from the translator’s POV. Programmers might think putting up a disruptive warning is a good thing, but this disrupts our thought process, taking us out of “flow” (not to mention a timeout of 3 seconds is unreasonable, especially when we’re typing template calls); so in addition to potentially causing user errors, the current way of presenting the warning can have the potential to cause translation errors.