This is a very unideal situation. Wikidata_IB, one of the recommended packages, can trigger this error simply by having a script calling checkvalue, on a random item that looks empty in the Wikidata interface, even. To say this is confusing is an understatement.

PS: If you expect people to turn on editor highlighting then fix all the highlighting error first.

If that’s the error, then the error message is faulty. It also works in preview, so browsers have no issues with the comma, it’s just the sanitizer.

And this isn’t a feature. This is an outright bug.

This is really important, especially for things like superscripts and subscripts, where oldstyle figures need to be disabled. If you don’t allow this then at least allow font-variant-numeric. This is making things very difficult for template and module writers.

@Jdlrobson: My understandingg is @H78c67c has already written a replacement and the admins will eventually sort things out and replace the broken gadget. So speaking long-term, tipsy’s removal should not be an issue on yuewiki. What I’m concerned about is the general failure to realize tipsy is used on zhwiki, yuewiki and commons in ways that cannot be meaningfully called “user”.

It’s not. Typography is fixed (which is a much welcome improvement. Thanks), but functionality is not. I don’t understand the script/gadget in question to know what’s happening, and no error is showing in the console.

@Jdlrobson: I am the one writing the Cantonese translation of Tech News since some 6 months ago. I translated the Tech News about tipsy’s removal; as a user, the change still shocked me (I didn’t write the system script in question, someone from another, bigger wiki wrote it) and when I reread the Tech News item even I could not understand how to switch over.

I want to comment on two very disturbing things the way this task was done:

1. The task identified that “removal will impact 342 user scripts” but failed to identify that removal will impact systemwide functionality on at least two wikis.
2. The Tech News writer was misled into thinking we can “read more” about switching to OO.ui.PopupWidget but all the provided links offer no explanation.

This suggests no one in development has even thought of the possibility that these jquery components that they’re planning to remove could affect system scripts — not just “user scripts” — and had done no research on actual impact. Something needs to change.

Fixed in production? Where I came from “production” means what’s already deployed in the field; from what I can see this is not fixed in the field.

In T334249#8766163, @Tacsipacsi wrote:

Disambiguation items (items having P31 = Q4167410) are conceptually different from non-disambiguation items.

In T334249#8765366, @Aklapper wrote:

@Al12si: What is "merge.js" or where to find it? Please do include links if applicable. Thanks.

Alternatively, “Wikipedia disambiguation page” descriptions should be disallowed and removed from Wikidata. All disambiguation pages represent some actual concept in some languages, and a page’s isambiguation page status is already described by a Wikidata relation; adding these descriptions is not DRY and is only going to cause errors, such as as what I wrote above.

This is also racist. The actually experimental “interlinear” is needed for Taiwanese ruby. MDN says no browser supports it, but if this isn’t allowed (since ruby-position isn’t itself allowed) no one will use it and therefore no browser will be pressed to support it. Is WMF promoting bad coding practices?

This is a silly statement. As I mentioned, it’s been working for years. MDN doesn’t mark it as experimental and tells people all browsers support it. No one is going to check whether it’s in an editor’s draft; they’ll just check MDN, see that all browsers support it, and assume it’s in the standard.

BTW, I won’t be so concerned with wrong punctuation, provided the MT engine, as a final step converts the punctuation (most of the time punctuation can be converted). However, this can’t be said of the comma and quotation marks (and maybe also the period) – I’d be a lot more concerned about any MT engine that gets commas, quotation marks or periods 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 that not only should MT be disabled (not reverted to opt-in, but outright 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 (I’d assume many other non-Mandarin Chinese languages are doing the same thing and I have reason to believe we’re actually quite far ahead of some of them). 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 is 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) today. 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% turned out to be wrong (and I’m still not sure if I missed anything). 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.