Jump to content

Support/Archive/2023/05

From translatewiki.net
Archive icon This is an archive page for the Support page. Do not post new threads here, they will likely not be read. If you wish to continue an archived discussion, start a new thread on the Support page and include a link to the archived discussion.
Archives
2023
  • Jan
  • Feb
  • Mar
  • Apr
  • May
  • Jun
  • Jul
  • Aug
  • Sep
  • Oct
  • Nov
  • Dec
2024
2025
  • Jan
  • Feb
  • Mar
  • Apr
  • May
  • Jun
  • Jul
  • Aug
  • Sep
  • Oct
  • Nov
  • Dec

Make a language variant active

Hello! I want to have the language variant Crimean Tatar (Romania) active for translation, I know language and I want to translate.TayfunEt. (talk) 14:45, 27 March 2023 (UTC)

I searched a bit, and I see that there is a Turkic language with a standardized Latin alphabet in Romania, so it's probably valid to add it. But is it specifically Crimean Tatar? Is this language code used on any other websites? Amir E. Aharoni (talk) 19:22, 31 March 2023 (UTC)
Hi Amir E. Aharoni, most of the Tatars there are from Crimea, they speak Crimean Tatar but have a different dialect (mostly known as Romanian Tatar) with his subdialects. Here are some more informations; https://www.academia.edu/19984869/Romanian_Tatar_language_communication_in_the_multicultural_space, https://www.researchgate.net/publication/287996468_Ekstra_Kucuk_Bir_Dil_Olarak_Romanya_Tatar_Turkcesi_As_an_Extra_Small_Language_Romania_Tatar_Turkish

The language code crh-latn-ro or crh-ro is actually not use, but I found this; https://machinetranslate.org/crimean-tatar. Probably crh-ru is for Crimean Tatar Cyrillic/Russia, crh-ua for Crimean Tatar Latin/Ukraine and crh-ro for Crimean Tatar Romania. TayfunEt. (talk) 07:16, 1 April 2023 (UTC)

OK... As I said, it can probably be added, but I want to do it well. I'll need some more details for this. What exactly do you plan to do with it? Do you want to create a Wikipedia in it? Do you plan to use it on any other wiki? Do you want to add a variant or a converter to the existing crh.wikipedia? Something else?
The Wikimedia Language committee doesn't allow new editions of Wikipedia in language variants without their own ISO codes, and even in some languages with their own codes if they are mostly identical to other languages (the common examples are Dari and Montenegrin). They may be allowed for localization on translatewiki, but it will help to understand what is the intention exactly. Amir E. Aharoni (talk) 05:53, 11 April 2023 (UTC)
The Crimean Tatar Wikipedians Visem and VolniyLev are in the same Idea. The Idea is, to put a alphabet converter in Crimean Tatar Wikipedia and translate in Translatwiki.net with the dialect. This means the pages will be available in the alphabet from Romania and the translations from Translatewiki.net in the dialect. For first a variant needs to be added for Crimean Tatar, which needs to be active for translate in Translatewiki.net. TayfunEt. (talk) 06:16, 11 April 2023 (UTC)
Will this alphabet converter be to the Romanian standard? Or to the Ukrainian Crimean Tatar standard? Or both? Amir E. Aharoni (talk) 14:34, 14 April 2023 (UTC)
There is converter for Ukrainian Crimean Tatar; Crimean Tatar (Latin). This one needs to be for Romanian; Crimean Tatar (Romania). The alphabet used in Romania includes all letters in Ukrainian Crimean Tatar + Ĭ and W letters. See Portal:Crh/Latn-Ro. And I would beg to get the variant active for translation in Translatwiki.net early, because I have not much time. I did also make a Task in Phabricator; https://phabricator.wikimedia.org/T332922. TayfunEt. (talk) 17:04, 14 April 2023 (UTC)
Wouldn't it be easier to make a converter from Romanian-Tatar to Crimean Tatar in the Crimean Tatar Wikipedia? If this requires activating the above, then I think it's worth doing it. Run Li (talk) 16:20, 20 April 2023 (UTC)
Hi @Run Li! There is an converter idea in Phabricator for the alphabet in Romania. We want also an variant for translation in Translatewiki.net. TayfunEt. (talk) 17:39, 25 April 2023 (UTC)
OK, I'll probably add it as crh-ro, but I also have a question about the orthography. There's this dictionary, which looks professional and well-made, but it appears to use a different orthography, for example í and î instead of i and ı (dotless i). Is the orthography that you plan to use documented in a reliable source? Amir E. Aharoni (talk) 06:03, 30 April 2023 (UTC)
Yes Amir, but this dictionary is written with the old alphabet (See ruwiki). The now used alphabet doesn't use this letters, here is a page from the book ALFABE, which is used in schools in Romania for Romanian Tatar. I think it is also good to use crh-ro, you can name it "Romanian Tatar", because it's mostly known with this name, the native name is "tatarşa". And don't forget to look or edit Phabricator and Portal:Crh. TayfunEt. (talk) 16:24, 1 May 2023 (UTC)
Can it have a less ambiguous native name? The name "tatarşa" alone, even if it's not identical, is too easy to confuse with Tatar, and "qırım tatarşa" is too easy to confuse with Crimean Tatar. Perhaps "qırım tatarşa (Rumaniye)"? I usually don't like adding countries in parentheses, but it's probably justified in this case. Amir E. Aharoni (talk) 07:29, 2 May 2023 (UTC)
Amir I would beg you to use "tatarşa", it's the easiest way and the common native name. It will not be problematic, because Volga Tatars don't use Latin alphabet often and they can see the different between "ş" and "ç". TayfunEt. (talk) 12:20, 2 May 2023 (UTC)
OK... I'll start with that. If it creates any issues, I may change it. Amir E. Aharoni (talk) 14:49, 2 May 2023 (UTC)
It's enabled now. Amir E. Aharoni (talk) 10:38, 3 May 2023 (UTC)
Thank you Amir! I have a question, did you put the English name of the language, because I see here only crh-ro and the native name? TayfunEt. (talk) 12:06, 3 May 2023 (UTC)
The current configuration is enough for translation, but you may still see a wrong name in the language selector for some time, because the name in the language selector is configured and deployed separately for technical reasons. It will be fixed in a few days and appear as "tatarşa" everywhere. Amir E. Aharoni (talk) 12:27, 3 May 2023 (UTC)
Thank you very much! TayfunEt. (talk) 12:31, 3 May 2023 (UTC)

Bug of Translate UI: messages displayed in English are forced to lowercase in the message editor.

@Jon Harald Søby: @Nike: @Raymond: @Abijeet Patro:

When translating there's a new bug that appears just now since a few minutes in the Translate UI on Translatewiki.net:

When we select a message to translate, the source message displayed (in English) is unexpectedly modified with all letters forced to lowercase. This causes incorrect translation or unexpected changes of validated translations when reviewing a message group or recent translations.

The real original in English is displayed in the list of messages, as long as we don't click it to open it in the edit form. However if this is the noly message displayed in the message group (e.g. it is the only one to translate or review in group, or selected by a notification received by email), we don't see the true original: we first need to dismiss the message editor by pressing "Cancel" then select the message again. We cannot translate and type with the original in English still displayed.

This bug is very recent since today after about 21:00 UTC (23:00 CEST). It occurs in EVERY message to be translated or reviewed, and in all message groups and all target languages !

I suspect the bug is a recent change is the Javascript of the Terminology gadget, using incorrect code to insert its coloring of terms (even if here there's nothing to change or when we have the gedget theoretically turned off), using some bad regular expression

Verdy p (talk) 23:07, 2 May 2023 (UTC)

  • As well, single quotation marks ' in the source message are also transformed into numeric character references ' within the displayed message, e.g. on Translations:Template:Related/1/fr.
  • Note that these bugs only occur in the edit form of the Translate UI (in creation, editing or validation modes), not in the Mediawiki editor which shows the source message normally.
  • Note that there's no error logged in the browser's console, except the old warning displayed only when the TranslateUI page is loaded and caused by mw.loader.implement("jquery.ui@erowa",...) at "ad.php?lang=fr&modules=jquery%2Coojs-ui-core%2Coojs-ui-widgets%7Cjquery.ui&skin=vector&version=15aic:405": « This page is using the deprecated ResourceLoader module "jquery.ui". Please use OOUI instead. »; plus some minor performance warnings ("[Violation] 'requestIdleCallback' handler took 75ms") which occurs regularly when the TranslateUI performs some background XHR requests and wants to reflow the page view (probably using a slow/costly jQuery code).

This is a problem in the Javascript of the Translate UI, that does not work correctly when the "Terminology gadget" is enabled in user preferences. If we disable that gadget, all is OK. It seems that the gadget uses unsafe regexps to lookup and transform source messages in the edit form to colorize terms defined in the Terminology gadget, or that it is incorrectly decoding the JSON data when there are some characters used in defined terms.

The code causing that bug is apparently caused by the tricky regexp (built from the termlist), used to transform the HTML content of the loaded source message in order to insert "data-term" spans, in: 

        function processSourcemessage(element) {
            let $sourcemessage = element;
            if (!$sourcemessage.data("original"))
                $sourcemessage.data("original", $sourcemessage.text()).addClass("term-sourcemessage");
            let termlistDescending = Object.keys(termlist).sort(function(a, b) {
                return b.length - a.length;
            });
            let regex = new RegExp("(?<!&lt;|&lt;\/|&)\\b(" + termlistDescending.map(x=>mw.util.escapeRegExp(x).replace("\\-", "-")).concat([""]).join("|") + "\\p\{L\}+)\\b(?!&gt;|;)","gui");
            let text = $sourcemessage.data("original") || '';
            text = mw.html.escape(text);
            text = text.replaceAll(regex, function(x) {
                return '<span data-term="' + x + '">' + x + '</span>';
            });
            text = text.replace(/data-term=".+?"/g, function(x) {
                return x.toLowerCase();
            });
            $sourcemessage.html(text);
[...snipped...]
        }

Apparently there are unsafe replacements to lowercase of /data-term=".+?"/g, or the termlistDescending.map() call used to build the tricky regexp an unsafe x=>mw.util.escapeRegExp(x).replace("\\-", "-"). Note that the tricky regexp uses flags "gui" (global unicode ignore-case).

As well I don't understand why text = text.replace(/data-term=".+?"/g, ...) is called to change the data-term to lowercase after is has been generated with text = text.replaceAll(regex, ...). This should be done directly by return '<span data-term="' + x.toLowerCase() + '">' + x + '</span>';, instead of return '<span data-term="' + x + '">' + x + '</span>';, without the second global replace() (which apparently is too greedy).

Also I don't understand the need to sort the termlist by descending length, when the regexp built just joins all these (pretransformed) terms as alternatives with "|", that have no significant order in regexps. However it may eventually make sense in the "[...snipped...]" part , that further processes the generated children spans to locate common "extensions" of these terms (like English plural marks), or elsewhere in the gadget (I did not study or debugged the full code). Verdy p (talk) 12:49, 3 May 2023 (UTC)

I do not have that issue at all when translating into sms, smn, or se. -Yupik (talk) 13:53, 3 May 2023 (UTC)
I think this issue has been solved now. There was an invalid definition in Portal:Fr/terminology.json, so this would only have affected people translating into French (explaining why everything still looked fine to most of us, but not to Verdy p). I will try to add some validation to the gadget so that an error message is shown when the JSON doesn't match what it expects, instead of the script trying to parse stuff it can't parse. Jon Harald Søby (talk) 13:54, 3 May 2023 (UTC)

Rename User

Hi, I would to request to rename my username to "Zolgoyo", I use it also in other Wikimedia projects. TayfunEt. (talk) 14:48, 3 May 2023 (UTC)

@Zolgoyo: Done Done Jon Harald Søby (talk) 17:43, 3 May 2023 (UTC)
Thank you! Zolgoyo (talk) 17:57, 3 May 2023 (UTC)

Verdy p is edit warring and making weird edits again

  • Ignores the ongoing discussion on MediaWiki Talk:License/fr and edit war.
  • Translates/modifies what’s inside var tags when the /qqq explicitly says not to ([1][2], etc.).
  • Removes the first uppercase letter on all French messages in Special:PrefixIndex/MediaWiki:Exif (the labels in the first column of the metadata table under each file, example), doesn’t respond when asked why (there has been a similar issue regarding languages where an admin told him "Don't change it to lowercase again.")

He has been warned and blocked multiple times for edit warring, this is becoming very tiring. Thibaut (talk) 07:50, 4 May 2023 (UTC)

About License: I read the discussion. As far as you ask me, I'm probably inclined to "License", but I don't know French well enough to understand all the nuance. If something special is needed there, it should be discussed by the community and documented in the localization guidelines, because licenses are mentioned in a lot of messages. And if this message needs some special treatment, it probably applies not only to French, but to other languages, so it should be documented in qqq.
About the } in the var tags: @Verdy p claims that writing one brace "causes problems". In all the languages, it is translated with one }, and I haven't seen problems that it actually causes. If it does cause problems, and I'm failing to notice them, they should be brought up here so that they could be fixed (probably in a separate section).
About the lowercase in EXIF messages: perhaps it was caused by the bug that was discussed in the "messages displayed in English are forced to lowercase in the message editor" section right here on Support recently. Maybe thee's no malice here, but it would be much smarter on @Verdy p's behalf to check carefully why do the messages look different before editing so many of them.
But generally, @Verdy p does show a years-long pattern of being too argumentative. His very high productivity is mostly good, but productivity is not a justification for continuous conflicts. I try not to get into arguments within a certain language community without a particularly good reason, especially when that language has multiple active and skilled translators, as French does. However, when there's a repeating pattern of disruptive behavior and complaints about a certain user, this will eventually require administrator action. @Verdy p, please consider yourself warned. Amir E. Aharoni (talk) 12:13, 4 May 2023 (UTC)
This is due to sources that were showing initials in lowercase, and I did not notice it immediately. I thought these messages in EXIF were changed in English to user lowercase (see above when I signaled the problem, I then searched for a possible reason). I can revert these to user uppercase initials and won't reject these. But no one signaled that before it was complained here without first asking.
As well there's no actual change of what is displayed in "/qqq": if one brace is URL-encoded for technical reason, the other matching brace should be URL-encoded as well for the same reason and to keep the expected pairing that should match. Yes this causes technical issues for encoding only one, but not both or none.
As well the English term to be translated was "Licensing", not "License": licencing may include one or more licenses, or none at all , and other conditions (e.g. the "public domain" is not a license as it is not universal and revokable, it is not granted explicitly and contractually for set by national laws and it is reversible and can be reappropriated, the public domain does not reliably protect the authors and the reusers; there are public-domain-like licences however like CC0, which is not defined by national laws and is contractual).
As well I have replied to a few messages this morning, before someone complained here without replying. I have not ignored these messages, but did not take other measures as I was absent from the site yesterday night and most of this day except for a few minutes this morning. Verdy p (talk) 14:30, 4 May 2023 (UTC)
“I have not ignored these messages, but did not take other measures as I was absent from the site yesterday night and most of this day except for a few minutes this morning. “
You certainly had time to make that third revert early this morning though, fully knowing that a discussion was ongoing and that no consensus was reached yet, hence my message here.
I see that you’re reverting your edits on the EXIF messages, thank you for that. Thibaut (talk) 15:01, 4 May 2023 (UTC)
> Yes this causes technical issues for encoding only one, but not both or none.
I still don't understand what issues does it cause. Amir E. Aharoni (talk) 15:38, 4 May 2023 (UTC)
Unpaired braces (this is, or should really be, a validation error in all messages, various QA tools assert and signal this condition for paired punctuations). Verdy p (talk) 15:46, 4 May 2023 (UTC)
This isn't, and in these messages this shouldn't. Amir E. Aharoni (talk) 16:32, 4 May 2023 (UTC)
That's your opinion. But even if this is not changed in English to make things coherently, this contradicts common goals, and making things coherently in a translation and in a way that is not even disruptive and is technically correct, is definitely not a problem at all you can complain for these translations. (proofs have been made in the past where the absence of QA validation rules caused changes later to be required in English, as well as all translations unless they were already correct and validated: this just saves time for later). Personnaly I think that URL-encoding only one brace in English and not in the other one is a bad quirk, not stable to be kept for the long term, even if it works as is for now, and it does not really help translators. The quality validator in TWN already tries to match pairing punctuations (it does that for parentheses and square brackets, but I don't see why it does not do that for braces, even if mismtached braces in translations can be real problems in many messages). Verdy p (talk) 17:51, 4 May 2023 (UTC)
Sorry but this morning I made the strict minimum for a few minutes but I was too tired to continue, just woken up to feed my cat. Then I was busy for the rest of the day till mid-afternoon. And note that I'm not alone here to change some wordings (even if there's no visible change in the English source also needing to apply them constantly). E.g. somewone this morning decided to change "badge" into "insigne" (both are valid, wellknown and defined in French dictionnaries, but the term "badge" is widely used in various common UI's, e.g. in Windows and Android and there was problem of understanding). Verdy p (talk) 15:43, 4 May 2023 (UTC)
@Verdy p I understand, I accept your apologies.
About Urhixidur, I'm actually writing a post about it on Portal talk:Fr. Thibaut (talk) 15:45, 4 May 2023 (UTC)
@Verdy p: Thread:Portal talk:Fr/Remplacement de mots en français européen par des québécismes. Thibaut (talk) 15:59, 4 May 2023 (UTC)
Note that the changes to lowercase was not made exactly like what was displayed in English: I did not force the lowercase when French requires a capital that I have kept. So not all EXIF messages were changed (those that were changed was just to be consitant, because there were pending changes displayed with yellow notices in the review, and I made that consistantly in that message group, preserving the French rules always. Now that I see that this was a UI bug, I have restored only the capitals used in English, even if some English message do not always use capitalized words; as well I never use the English "titlecase" style in French translation: even Wikimedia recommends not using it in most places if they are not true work titles, so for example section headings or table headers are not eligible; "title casing" is favored in fact only in US by some editors that abuse it for everything, where normal/grammatical casing rules should be used). The UI bug in TWN was signaled by me (here first, then in Telegram when I saw no response) and that problem occured for less than 24 hours when we could find its reason. Verdy p (talk) 15:55, 4 May 2023 (UTC)
(in French) À la décharge de Urhixidur et de Thibault, c'est bien aussi que d'autres commence à s'intéresser à la relecture des vieilles traductions des groupes de messages de MediaWiki (bon nombre n'ont jamais été relus correctement et complètement). Je sais qu'il y en a beaucoup c'est long et très ingrat à faire (et parfois ça peut provoquer des "couacs" sur des nouveaux désaccords alors qu'en fait il n'y a jamais eu de consensus établi et souvent encore moins de cohérence. Quand on relit et qu'on tente d'apporter de l'homogénéité, on tente de préserver l'existant autant que possible, on tient compte aussi d'autres cas d'usage apparus depuis où des distinctions sont nécessaires et utiles. On peut en discutersi un désaccord apparait sur un message ou quelques uns, mais si on cherche un peu, on trouvera aussi que cet accord n'existait déjà pas (il n'y avait pas de cohérence). Rendre cohérent selon un choix possible permet cependant d'améliorer l'efficacité des outils de recherche de messages et de les revoir alors tous ensemble (ce qui n'était pas possible avant, et qu'on ne trouve même souvent aucune trace de discussions antérieures, ou que ces discussions parfois se sont contredites entre elles en portant chacune sur une partie des messages, parfois même dans le même groupe de messages).
Pas la peine de monter le ton et vouloir y voir malice ou une action malveillante : c'est l'occasion de discuter et pas de se plaindre ! Malheureusement la relecture est laissée de côté par trop de monde, qui pourtant apprécient le travail massif de traduction effectué dans MediaWiki et les efforts de cohérence, mais ne se posent jamais la question des vieilles traductions jamais relues (où se dissimulent souvent des tas de fautes d'orthographe, une ponctuation incohérente, des anglicismes non nécessaires, des erreurs d'interprétation (l'anglais source peut être souvent ambigu et les cas d'ambiguïté sont souvent mal signalés et documentés). Je fais ce travail depuis longtemps et autant que possible en vérifiant chaque groupe de message en entier pour assurer cette cohérence (je ne me contente pas de juste ce qui est nouveau et qui vient s'ajouter de façon incrémentale et souvent incohérente avec le reste déjà traduit: j'utilise donc abondamment les outils de recherche et m'occupe toujours de vérifier les groupes de messages dans leur entier, ce qui est essentiel justement pour la relecture et qui prend en fait beaucoup plus de temps et est beaucoup moins facile qu'une traduction immédiate qu'un robot pourrait faire, la relecture est une tâche entièrement humaine).
Il n'y a pas eu non plus de "guerre d'édition" comme prétendu (la discussion mentionnée plus haut a eu lieu après et j'y ai participé et répondu, ce n'est qu'ensuite dans la journée que Thibaut est venu se plaindre ici alors qu'près ma réponse rapide dans cette discussion tôt ce matin, je n'ai rien fait du tout de plus dans la journée avant de voir ce fil de discussion ici en fin d'après-midi, la discussion mentionnée n'a fait l'objet d'aucune réponse après la mienne !).
Quant au message envoyé il y a 23 heures dans ma page de discussion, je n'étais pas connecté, j'étais sorti en balade hier depuis la fin de l'après-midi jusque tard dans la nuit (pour profiter du beau temps, comme beaucoup d'autres à Niort pour cette vraie première soirée estivale) : je ne pouvais pas y répondre avec mon téléphone déjà déchargé; j'ai vu seulement ce matin tôt cette discussion ici avant même m page de discussion et commencé à y répondre mais j'étais trop fatigué pour continuer au delà de quelques minutes). Bref je n'ai rien ignoré du tout mais ce n'était pas le bon moment pour répondre dans la précipitation alors que le ton était déjà monté ici beaucoup trop vite ! Je suis souvent connecté, mais pas tout le temps, j'ai le droit aussi de sortir un soir et aussi le droit de dormir. Et personne ne m'avait non plus notifié hier avant que je sorte alors que ces modifs problématiques ont été faites la veille. Merci d'accorder au moins le même délai humain, je ne suis pas un robot. De le messages ci-dessus et sur Telegram n'avait eu aucune réponse pendant plus de 24 heures (là aussi ce sont des humains pas des robots, et ils ont eux aussi d'autres choses en cours dans leurs activités à suivre). Dans le cas présent il n'y avait non plus strictement aucune urgence à agir, c'était linguistiquement correct et sans anomalie technique insurmontable et rien n'était encore expliqué. Ce n'est pas raisonnable du tout de hausser le ton à cause d'un délai de quelques heures, alors que ces relectures nécessaires (et demandées) sont en attente depuis des années !
Merci donc pour ceux qui comprennent que ce n'est pas toujours aussi facile qu'ils le croient: c'est très facile de se plaindre tout de suite quand on a soi-même fait aucun effort (ou trop peu) pour relever les vieux problèmes existants sans tenir compte de la masse d'efforts consacrés depuis longtemps à relire (la relecture prend en fait bien plus de temps que la traduction, d'autant que les anciennes traductions ont été souvent faites à la va-vite, parfois même de façon automatique sans modification humaine ! (Et désolé si je prends moins de soin pour la rédaction initiales des discussions, souvent il faut là aller vite pour éviter une escalade, et je corrige un peu après, mais je me fiche là de la ponctuation idéale, le but étant d'abord d'être compris et ne pas laisser trainer les choses). Seulement ici on trouve certaines personnes qui n'ont aucune patience et préfèrent juste se plaindre et ne font pas grand chose pour aider, expliquer et décider sereinement comment résoudre les problèmes identifiés. Verdy p (talk) 17:33, 4 May 2023 (UTC)
C’est dommage le message commençait bien.
"Il n'y a pas eu non plus de "guerre d'édition" comme prétendu (la discussion mentionnée plus haut a eu lieu après et j'y ai participé et répondu, ce n'est qu'ensuite dans la journée que Thibaut est venu se plaindre ici"
Tu as participé à la discussion à 01:55 UTC mais tu as ensuite remis ta propre version à 01:59 UTC malgré deux personnes pour le moment qui sont pour « Licence : » et sans attendre qu’il y ait consensus, c’est bien une guerre d’édition et c’est ça le problème et ce n’est pas la première fois (sinon je ne serais pas venu ici). Thibaut (talk) 18:18, 4 May 2023 (UTC)
Note qu'Urhixidur continue à introduire des québéquismes dans divers projets. Je veux bien qu'il y en ait mais il faudrait alors demander l'ouverture des traductions pour la variante "/fr-ca", qui pour l'instant est fermée. De plus ton message plus haut ne pas attendu un temps raisonnable. Ce matin j'ai essayé de répondre pendant quelques minutes mais j'ai bien vite vu que je n'avais pas assez dormi. Tu aurais pu attrndre quelques heures alors que ce sont des messages non relus depuis des années et que techniquement ou linguistiquement il n'y avait aucun problème nécessitant une action urgente. Je le redis ici : je ne suis pas un robot joignable à la seconde et on peut bien y consacrer un peu de temps avant de révoquer une chose qui est techniquement correcte et ne provoque strictement aucun dommage. Personne ne s'était interrogé avant de la pertinence des anciennes traductions rapides et précipitées parfois largement automatiques et pas relues du tout ensuite). Verdy p (talk) 18:32, 4 May 2023 (UTC)
@Verdy p : L'absence de commentaire de modification faisait franchement penser à une volonté de passer en force malgré la discussion. Thibaut (talk) 18:39, 4 May 2023 (UTC)
Regarde l'heure (4 h du matin en France: je ne me suis réveillé que pour mon chat aprsè seulement 2 heures de sommeil et une longue balade épuisante la veille) et ce que je faisais à ce moment-là (et ce que je ne faisais pas depuis la veille ni après aujourd'hui avant ce soir). Franchement, vu ma trop grande fatigue, j'ai préféré suspendre et attendre un peu, ce qui est tout çà fait normal pour les utilisateurs humains que nous sommes (et c'est même demandé, on doit être en état de réagir correctement). Et là encore il n'y a aucune urgence à agir (pas plus à faire un revert avant d'avoir lancé la moindre discussion pour ensuite se plaindre ici sans attendre une réponse dans un temps humain raisonnable pour un vieux problème existant depuis des années et jamais discuté avant). Verdy p (talk) 18:47, 4 May 2023 (UTC)
Du coup si t'étais fatigué et que tu devais nourrir ton chat (je vois qu'on aime tous les deux les chats, au moins nous avons un point commun), pourquoi ça pressait tellement de revenir à la version précédente ? Thibaut (talk) 19:18, 4 May 2023 (UTC)
Parce que je me suis rendu compte que je m'endormais à nouveau, malgré le café (que je n'ai même pas eu le temps de finir et que j'ai retrouvé froid sur la table quelques heures après). Mon attention était perturbée : tu aurais préféré que je continue ? Ceci dit, c'était un clic unique, qui ne cassait rien et sans aucun caractère d'urgence (pas de quoi fouetter un chat !). D'ailleurs c'est elle qui, une fois repue, est venue me remettre au lit pour qu'elle se couche à mes pieds. Ca pouvait donc bien attendre quelques heures après des années d'inaction. Verdy p (talk) 21:19, 4 May 2023 (UTC)
Il est évident que les chats ont la priorité, merci pour l'explication. Thibaut (talk) 11:04, 5 May 2023 (UTC)

@Amire80: "[…] especially when that language has multiple active and skilled translators, as French does." : unfortunately that is no longer the case, we're only two active translators/reviewers atm (there's currently another one but he's just here to impose regionalisms and ignores discussions where he's notified) and it is very difficult when there's a disagreement on a translation to have second opinions (like here for example, not blaming Verdy p here, not his fault of course).
I tried to make some promotion on the French Wikipedia village pump, but in vain. Thibaut (talk) 11:03, 5 May 2023 (UTC)

If discussions happen on pages with LiquidThreads, I don't think it will notify translators with Echo like we're used to from normal talk pages. So it could be that Urhixidur is simply not aware those discussions are happening. I suggest notifying them with a message on their user talk page. Jon Harald Søby (talk) 12:31, 5 May 2023 (UTC)
I see, done. Thibaut (talk) 13:04, 5 May 2023 (UTC)

Rek Dinka

The Modified or unified Thuoŋjang ( din ) is not easily read and written which make it hard to translate new articles. With this am requesting for Simple version of Rek Dinka and standard to exist and be able to provide information based on it standard and forms in the curriculum and syllabus available.

[3] Wen Dengdit (talk) 21:21, 6 May 2023 (UTC)

Thanks for the request. Please give me a couple of days to check this. Amir E. Aharoni (talk) 08:06, 9 May 2023 (UTC)

MediaWiki:Newsletter-edit-subscribers-nochanges/en

No changes have been made to the subscribers of the newsletter.

It's not the subscribers that are changed (that would entail modifying user accounts), it's the list of subscribers: 

No changes have been made to the list of subscribers to the newsletter.

Urhixidur (talk) 11:27, 7 May 2023 (UTC)

@Urhixidur: Thanks for the report! I have uploaded a patch based on your suggestion. Jon Harald Søby (talk) 07:59, 9 May 2023 (UTC)

MediaWiki:Logentry-newsletter-newsletter-restored/en

Shouldn't

$1 {{GENDER:$2|restored}} newsletter $4

rather be

$1 {{GENDER:$2|}} restored newsletter $4

? Urhixidur (talk) 14:32, 6 May 2023 (UTC)

{{GENDER:$2|restored}} is better because it gives a hint to the translator what should it be applied to. It's not the same in all languages, and English doesn't need it at all most of the time, but it's nevertheless the best compromise. (Besides, your suggestion will probably add two spaces in English.) Amir E. Aharoni (talk) 18:05, 6 May 2023 (UTC)
Speaking of magic words, could we discourage these kind of changes: [4][5]? While it may save a few milliseconds for the server, it takes a longer time for reviewers to check if it is correct, this is completely unreadable and increases the chances of mistypes (I had to correct a few). Thibaut (talk) 18:14, 6 May 2023 (UTC)
Most likely, it saves zero milliseconds. Nobody should use this argument. I can imagine some other arguments, but this one is not relevant.
It was already discussed at Thread:Support/PLURAL_and_GENDER_optimization, and I won't repeat everything. Discuss it withing in the French community, agree on something, document it on Localisation guidelines/fr, and use it consistently. Amir E. Aharoni (talk) 10:40, 7 May 2023 (UTC)
Weird. I'd rather have $1, $2, and $4 documented in qqq. Urhixidur (talk) 01:21, 7 May 2023 (UTC)
Both things are useful. Amir E. Aharoni (talk) 10:28, 7 May 2023 (UTC)
@Amire80: this is a false hint, the gender does not apply to the verb, not as you think, and at least not universally the same way across languages. The gender may be taken from the subject of the object, and in addition the verb itself may be reflexive, or not, or used with a passive form; as well the subject and object may need to be reversed (needing to changing a transitive verb to an intransitive one, or swapping the subject/object roles of the transitive verb, like in the English verb to miss after it is translated). Such thing is just bad. In fact, the English source should better use {{GENDER:$2|$1}} restored newsleter $4, to show explicitly that $2 (using a user page name) and $1 (the displayed user name) are referencing the same user. detaching it from the actual user and attaching it to another unrelated verb just causes confusion, making assumptions about how to translate these verbs, and incorrectly assuming a grammatical form!
As well the assertion that it would "insert two spaces in English" is also false with this form: $1{{GENDER:$2|}} restored newsletter $4, or equivalently {{GENDER:$2|}}$1 restored newsletter $4, and I do not see where that form can be less clear to any translators to any languages and how this can slow down or complicate the work of translating or reviewing (in fact that's the opposite!).
This may look OK for you if you think about it in Russian, but it is completely wrong in all Romance languages and as well in most Germanic languages, and makes no sense at all in English (where most native developers just have false assumptions about everything in other languages!). For most African and Asian languages, these hints are even more confusive! Given all that, English sources should do the minimal needed: using an empty {{GENDER:$2|}} somewhere in the message (at start or at end, or closest to the displayed variable with which it is REALLY related) is the best thing to do: iut just shows the GENDER is supported, but that it is optional and languages can drop it if they don't need it (or it can be removed automatically when messages are exported and there's a single form, possibly empty, in the parameters to "GENDER:" or "PLURAL:", that can be extracted from it after dropping the surrounding braces, function name and the column; my opinon is that all those source messages in English should never pass any value in English after the opening brace, function name, colon, variable name and pipe, and before the closing brace). Verdy p (talk) 19:02, 10 May 2023 (UTC)

Moving "ignored" messages to separate JSON files

This is a rather internal, technical change, which is probably not going to affect end users, but correct me if I'm wrong.

In a few conversations, I informally raised the idea of simplifying the way in which configure "ignored" messages. Currently, they are added to projects like usual messages and configured in translatewiki's configuration. This works, but creates a duplication: something has to be done in two repositories, and it often happens that a new message that should be ignored pops up for translation for a few days before it's configured as ignored.

Here's my proposal to change it:

  1. Move all the ignored messages to separate JSON files.
  2. Configure those files as message files in the project's own repository.
  3. Don't mention those files in the translatewiki configuration, so that translatewiki doesn't see them at all.
  4. Stop using the explicit "ignored" section in translatewiki's YAML configuration files.

I also raised it at https://phabricator.wikimedia.org/T167762 some time ago.

If no one objects, I can start making test patches.

This proposal applies to MediaWiki core and extensions. It can probably be applied for most other projects, but I am not familiar with the way that other projects' load message files, so I can probably only make a recommendation about it.

Everyone's comments are welcome, but especially: @Nike, @Raymond, @Abijeet Patro, @Nemo bis, @Jon Harald Søby. Amir E. Aharoni (talk) 07:28, 5 May 2023 (UTC)

@Amire80 Sound reasonanble. 2 thoughts: 1) Does that mean, that for extensions with, let's say, 1 message to ignore another file like "en.ignore.json" would be necessary? And 2) How can we train the developers to add messages to ignore in a 2nd file? I see a lot of work for us to patch already merged patches, at least for the first few weeks/month? Raymond 10:23, 5 May 2023 (UTC)
  1. Yes.
  2. Kind of like we trained to put API messages in i18n/api several years ago. Over a few months, I and a few other people made a lot of patches to convert current extensions, and they were merged fairly quickly. I also updated the documentation on mediawiki.org and the BoilerPlate extension. By now, new extensions usually put the API messages in a separate file. Something similar can be done with ignored. People very often write code by copying existing code.
At some point, someone developed a script for converting the API messages quickly. The conversion of ignored messages can probably be done using a script, too, and in fact, I already started writing it. Amir E. Aharoni (talk) 10:32, 5 May 2023 (UTC)
+1 Sounds good to me, but someone else must approve. Jon Harald Søby (talk) 12:18, 5 May 2023 (UTC)
I'm not sure this is worth the effort for anything except maybe MediaWiki core. We still have the optional messages and it can be more confusing when those are handled differently.
If we want to give the freedom to decide to developers (I am not sure they are good at deciding without help), extension to the milkshake format would enable a better developer experience. Nike (talk) 13:46, 5 May 2023 (UTC)
Not experienced enough to vote about this, but perhaps we could expand the same logic to optional messages as well if there's consensus to move forward? —MarcoAurelio (talk) 09:55, 11 May 2023 (UTC)
The same logic cannot be easily applied to optional messages. It's easy with ignored messages: put them in the code, but don't configure them on translatewiki. Optional messages must be configured on translatewiki because they may need translation to some languages. If there's already a way to configure a whole file as "optional", then it can be done. If there's no such way now, I wouldn't prioritize developing it. Amir E. Aharoni (talk) 09:59, 11 May 2023 (UTC)

About Wikimedia:Twinkle-prompt-reason-restore/en

There are 30+ extra whitespace characters at the end of the message. I'm not sure if this is intentional or if it is a bug. Shirayuki (talk) 05:17, 14 May 2023 (UTC)

I created a pull-request: https://github.com/wikimedia-gadgets/twinkle-core/pull/27 Nike (talk) 08:53, 30 May 2023 (UTC)

Saraiki language

Code for Saraiki language is used skr-arab. When Saraiki language is employed in sites it uses Urdu or Punjabi translations in many places in the sites. I think this is due to fallback. So this problem be solved. Urdu and Punjabi translations should not be shown. 2nd problem is that in many place translated to skr-arab are shown in English for example Islamic months are translated https://translatewiki.net/wiki/MediaWiki:Hijri-calendar-m10/skr-arab But in https://skr.wikipedia.org/wiki/سانچہ:تقویم_صفحہ_اول it is English language. This problem also should be solved. Saraiki (talk) 09:10, 10 May 2023 (UTC)

@Saraiki: Hello!
There are two different (but interrelated problems) here. The first problem is that Saraiki has a somewhat unusual configuration, where there are two language codes in use: skr and skr-arab. The former is not used, and is just set to fall back to the latter.
Due to the way fallbacks work, they are not inherited. So because skrwiki (the Saraiki Wikipedia) is set to the language skr, it only falls back to skr-arab, while skr-arab's fallback of ur, pnb is essentially ignored.
The second problem about MediaWiki:Hijri-calendar-m10/skr-arab is related to the first problem. The message is not actually translated – it may appear to be if you just visit it, because it is actually displaying the fallback from ur. That, however, is not displayed on the Saraiki Wikipedia because that Wikipedia's fallback chain is essentially just skr -> skr-arab -> en; if you want the Wikipedia to also fall back to Urdu and Punjabi (it seems to me like you're requesting the opposite, though), we'd have to add ur, pnb to MessagesSkr.php in addition to MessagesSkr_arab.php. A better solution, though, and my recommendation, would be to set skrwiki's language to skr-arab directly, thus "bypassing" that fallback. This can be done via a request in Phabricator.
If you wish to remove the fallbacks to Urdu and Punjabi, we would probably need consensus to do that from the Saraiki Wikipedia and Wiktionary communities. But to be clear, what would happen then is that it would just fall back to English instead. Since Saraiki is a right-to-left language and English is left-to-right, the results may look worse (but it would be even more obvious what is untranslated), so there are pros and cons depending on which way you look at it.
Pinging @Amire80 to see if he has any further input. Jon Harald Søby (talk) 09:45, 10 May 2023 (UTC)
Hi @Saraiki, just to make sure: When a message is not translated into Saraiki, in which language should it appear: Punjabi, Urdu, English, or something else? Amir E. Aharoni (talk) 10:26, 10 May 2023 (UTC)
@Amire80 @Jon Harald Søby I think that if it is not translated, It should be in English only. Because this will show that this message is untranslated. Punjabi and Urdu are confusing. Saraiki (talk) 11:36, 10 May 2023 (UTC)
@Amire80 @Jon Harald Søby, I also tried at https://github.com/wikimedia/mediawiki/pull/156/commits/dbbc826a5ddea61900eb9dfbe7ca4d2d9edfa748
So these three changes be done please:
  1. Removal of fall back
  2. NS_USER_TALK => 'ورتݨ_آلے_نال_ڳالھ_مہاڑ',
  3. $linkTrail = "/^([آابٻپتٹثجڄچحخدڈݙذرڑزژسشصضطظعغفقکگڳلمنںݨوؤہھۃءیئے]+)(.*)$/sDu";
Saraiki (talk) 08:50, 14 May 2023 (UTC)
@Saraiki: Thanks! I added that patch (with a couple of minor changes) to Gerrit: gerrit:919467. Jon Harald Søby (talk) 14:55, 14 May 2023 (UTC)
@Jon Harald Søby Thanks very much Saraiki (talk) 15:26, 14 May 2023 (UTC)

Names of crh

Hi, I did see problems in some Crimean Tatar names:

  • Crimean Tatar (Latin);
    qırımtatarca (chirilic) → qırımtatarca (kiril)
    tatarca (România) →qırımtatarca (Romaniya)
  • Crimean Tatar (Cyrillic);
    татарджа (Румыния) → къырымтатарджа (Романия)
    къырымтатарджа (Кирилл) → къырымтатарджа (Кирил)
  • Romanian Tatar;
    tatarşa (chirilic) → tatarşa (kiril)
    tatarşa (România) → tatarşa (Romanya)

Zolgoyo (talk) 09:38, 14 May 2023 (UTC)

I can update them, initially there was no names at all (so they were already using fallbacks, except for the autonym of [crh-ro] which was set probably by Amire as just ""tatarşa" and not "tatarşa (Romanya)", but this was discussed above in the "Make a language variant active" discussion started in 27 March up to 3 May), but you're right they were based on Romanian (as a "reasonable" fallback). They were just initialized (basically for English used in category names). Look at these updates now. Verdy p (talk) 10:20, 14 May 2023 (UTC)
In Crimean Tatar (Latin) is written "tatarca (Romaniya)", it will be better when it is "qırımtatarca (Romaniya)" and for the code crh is written "qırımtatarca / къырымтатарджа", you can rename it as "qırımtatarca / къырымтатарджа / tatarşa". Otherwise all seems to be ok. Thank you! Zolgoyo (talk) 10:46, 14 May 2023 (UTC)
OK done, I added the third alias (second in Latin) for [crh]. Verdy p (talk) 11:37, 14 May 2023 (UTC)

Nuking all ArticleEditor404 translations to yue

As mentioned in the earlier Thread:Support/Low_quality_translations_by_ArticleEditor404, their yue translations are of extremely poor quality. Can an admin please nuke all their yue translations? Thank you. Hello903hello (talk) 23:58, 16 May 2023 (UTC)

Done for all languages. Nike (talk) 12:41, 17 May 2023 (UTC)

Translation request (MediaWiki editor toolbar in Turkish)

Can someone with the rights translate these please, thank you:

—Joseph (talk) 19:54, 17 May 2023 (UTC)

@Joseph Done now. Raymond 17:18, 18 May 2023 (UTC)
Thanks @Raymond.Joseph (talk) 18:36, 18 May 2023 (UTC)

Request for inclusion of Brazilian Sign Language

Its ISO language code is "bzs". Brazilian Sign Language (M525x528S14c0a476x498S14c11489x472S29904511x496 in bzs) is the first language of deaf communities in Brazil (so should fall back to pt-br). It has a test Wikipedia in Incubator and many lexemes in Wikidata. SignWriting (a vertical script) is the dominant writing system, but its Unicode is not used. To represent the signs, the wikis use ASCII strings, which can be properly displayed using code (like: 1 and 2). Translatewiki already supports American Sign Language, using the same mechanism. I'm making this request in order to add a monolingual language code to Wikidata (apparently, this is needed to the language to be requested here). I can myself translate basic sentences, and if necessary I can try contacting native speakers for help. EnaldoSS (talk) 17:48, 13 May 2023 (UTC)

Portal:bzs exists but shows that it's still disabled for now. However the "ASCII notation" used is not really a Latin transcription. it is a complex notation, like programming languages or SVG, and does not easily support plain-text searches (due to many numerical positions encoded, it requires a complex computing rule in search engines to round up them); as well it allows multiple encoding for various sequences (the current standard has not defined any canonical order for encoded writing blocks that are composed with multiple glyphs, each one have varable attributes, and the stadnard says that this order is not sdignificant in most cases (except some overlaps). Supporting that script would require extensive development, using properties that are still not encoded in Unicode; as well that notation does not want to use the encoded SignWriting unicode characters that should still finally be used to render the interpreted sequences by a custom renderer. may be tyhis will change later (possibly by adding other combining characters or grapheme joiners to the SignWriting Unicode block(s) and more properties like those defined for Emojis). For now I doubt this will occur soon (this is also the case for other scripts with complex layout, like Egyptian hieroglyphs, that are supported in a limited way for now in Mediawiki using a specific extension to render them as images, but very impractical for inputing text by common users). Supporting the script first requires developing an input method, then improving the search engine capabiltiies, then determine rules to generate a usable "canonical" form which could be the good base to develop a stable orthography for which it is possible to reach to a consensus and to make links between articles working as expected, without having to define tons of page redirects).
So for now, all that can be done is to propose a way to allow supporting OCR-like features, e.g. in Wikisource to reproduce existing documents with trustable and verifiable sources, that may otherwise only be represented by scanned or photographed facsimiles; it will be possible to define very short extracts of text, but very write inoovative texts editable by multiple persons (but it would be possible to use it to communicate privately between users, each one writing it as they want for their own talks). But it will be very hard to have a usable and maintainable Wikipedia or Wiktionnary for example with extensible, improvable and correctable articles, if we don't have a relatively stable orthography described by some standard (the existing source foundation for the SignWriting standard is still not ready for that, and is studying other forthcoming options, that may later need additions to Unicode and or CLDR, and possibly new standard algorithms). Verdy p (talk) 18:24, 21 May 2023 (UTC)
EnaldoSS, thanks for the request. I want to verify how should the name of the language appear: "M525x528S14c0a476x498S14c11489x472S29904511x496" or perhaps "Língua brasileira de sinais"? The American Sign Language appears as "American sign language". It's not necessarily good, but that's how it appears. --Amir E. Aharoni (talk) 12:05, 23 May 2023 (UTC)
@Amire80: "Língua brasileira de sinais" is ok. EnaldoSS (talk) 13:53, 26 May 2023 (UTC)
@EnaldoSS, this is now enabled. Amir E. Aharoni (talk) 10:52, 27 May 2023 (UTC)
The syntaxic notation is not really SignWriting, it's an ASCII notation that should be handled by a server-side extension (like WikiHiero) or by some client-side javascript plugin. It will be complex to do especially with the vertical layout, or with multingual contents. For now SignWriting characters from Unicode alone are not sufficient (it only encodes basic glyphs, and some modifiers for color filling or rotations, but not positioning within "signbox" clusters (there's no specied cluster joiners and modifiers to properly delimit the cluster boundaries; the vertical layout of clusters is a secondary problem (but this vertical layout is optional in SignWriting, exactly like it is with Han ideographs, Mongolian, or Yi scripts ; initially the SignWrting script was designed for horizontal layout, the vertical one was suggested to allow another refinement, i.e. horizontal placements for representing "roles" when there are multiple relaetd speakers and a central narrator: the whole signbox is moved to the left or right at different positions, that are easier to see in the vertical layout, but where the horizontal layout would require additional leading signs to specify the played roles; note also that signboxes do not rotate when switching between horizontal and vertical layouts, but this is not the case of punctuations which are horizontal in the vertical layout, but rotated and vertical in the horizontal layout; as well SignWriting does not specify the roles of whitespaces for justification of rows of text, which also switch their horizontal vs. vertical metrics; and it's not clear how signboxes are separated in true SignWriting, because they are invisible, but this separation is important for allowing break opportunities in long texts and some whitespaces may be used for that: in the ASCII-based notation, signboxes are sometimes represented using hyphens to join signs and modifications, and spaces and puntuations to separate them; all this is not specified in the current Unicode encoding, so these Unicode characters may only be used alone, but not for proper text, just like this is the case as well for Egyptian hieroglyphs).
A proper SignWriting translation would still need to be rendered as images, not as plain text, because this is still not possible, except for invidual signs that are part of signboxes, and for whitepaces and punctuations that do not participate to signboxes but separate them and have a simple linear layout, and that also are possible break opportunities (forbidden in the middle of signboxes). Verdy p (talk) 12:23, 23 May 2023 (UTC)
@Verdy p: Thanks for the detailed response. EnaldoSS (talk) 13:56, 26 May 2023 (UTC)

Favicon no longer displayed on this wiki.

This wiki uses the following code (in the page header) to specify a "favicon", the icon that should be displayed on tabs. These icons should be small 16x16 color bitmaps.

<link rel="icon" href="/favicon.ico">

However, recent version of Chrome/Chromium no longer displays these icons: notably the legacy "'.ico" format is no longer used (probably due to security reasons, as this is a Windows specific format that may embed active code; though webbrowser will discard/ignore this non-image content). This will probably be the case for other Chrome-based browsers (Chromium, Edge, Android). Chrome prefers now using the PNG format (which is safer and does not require proprietary tools to create them), like this:

<link rel="icon" type="image/x-icon" href="/favicon.png"> (you can see on example of use on Gmail's website and Google site)

The interest of the .ico format however is that it can embed several resolutions of the icon in the same file (this makes it easier to use them as well as desktop icons or menus for navigation shortcuts, at the price of a larger downloaded size). Windows suggests the following resolutions: 16x16, 24x24, 32x32, 48x48, and so on up to 128x128, to adapt to various display resolutions (e.g. on Hi-DPI devices or for larger thumbnail views). When a specific resolution is not available, icons will be scaled up or down from the nearest resolution, giving good results that don't look too blury at any practical resolution.

PNG images may be rescaled if their resolution is large enough, but may sometimes look blurry or insufficiently contrasted when scaled down, notably if they embed text (requiring some subpixel changes of the geometry, like with glyphs of hinted fonts). However some good renderers may use some autohinting algorithm to preserve contrast, colors and sharpness when scaling images at low size (this is used for example for rendering textures mapped on 3D surfaces with the mipmap technic implemented in hardware graphics accelerators used on all modern devices). Autohinting is not necessary when icon files are embedding images at multiple sizes on the scale suggested by the Windows documentation, because the filtering convolutions are simpler to implement in software only; with the use of modern graphics hardware, it is generally no longer needed, so icon files in PNG format may just be defined with a single suggested resolution of 64x64, and will look good at all sizes when the geometries are simple with a flat design (this is the case of the favicon for Translatewiki).

Other sites are suggesting this syntax (with another "shortcut" keyword in the rel attribute, so that it also works for creating shortcuts, e.g. on desktop, and a more standard value in HTML type="" attribute or HTTP(S) headers specifying the media type, however the effective media type should be the one specified by HTTP(S) headers when effectively downloading the icon, or when the icon is specified by a "data:" URL, encoded in Base64 with its prepended media type):

<link rel="shortcut icon" type="image/png" href="/favicon.png">

You may combine these lines on the same HTML page (the first that works will be used if other lines are not suitable). Without these favicons, using multiple tabs in a webbrowser complicate the task (adding the "shortcut" keyword is optional but may be fine to create desktop icons. I don't know if other graphic formats are supported (e.g. SVG, GIF or JPEG, but beside GIF they are probably useless for favicons). And maybe the favicons in .ICO format are no longer used if there's no "shortcut" keyword, just "icon", in the rel attribute. another possible cause is the currenty content of the "favicon.ico" file, which fails some internal safety checks made now by Chrome if it includes some unsafe extensions or if its data is not properly aligned and padded.

Can we have such PNG icons hosted? (note that Safari on Apple also uses PNG images for its touch interface) Does this require an update in MediaWiki? Verdy p (talk) 18:56, 16 May 2023 (UTC)

Recently came across https://evilmartians.com/chronicles/how-to-favicon-in-2021-six-files-that-fit-most-needs Nike (talk) 19:16, 27 May 2023 (UTC)
Really a nightmare. I don't understand why the W3C did not made a unified standard, allowing various formats, but recommanding one that can either support mipmaps (for bitmap icons), or SVG, or a syntax working like normal images in HTML (where you can specifiy a list of URIs for various scales or pixel resolutions, something that MediaWiki already supports). Chrome is apparently unstable across its versions, sometimes ICO files disappear and can't be rendered. Safari on MacOS or iOS also don't play the same game! (Note that my question above is not strictly about translatewiki.net, I've seen similar issues as well with Wikipedia, or any Mediawiki site in general, and creating shortcuts by dragging a link from a browser by to a desktop folder does not always work as well, depending on sites and the various tricky/unstable syntax and formats they use; so this is also a question that may be posted to MediaWiki developers and see how they intend to support this nightmare). Verdy p (talk) 19:42, 27 May 2023 (UTC)

Incorrect web font currently used for the Myanmar script

Since recently a new webfont was added on this site, however it breaks displays in many case: the "Tharlon" font replaces extended Latin letters with completely unrelated characters or symbols, most probably because it is not coded with Unicode but uses some strange mapping from legacy charsets. This is visible in all Myanmar translated pages that attempt to display non-Myanmar texts. For example it shows the incorrect glyph for '®' (U+00AE) instead of the expected 'é' (U+00C9).

Please disable that incorrectly encoded webfont (it is even deprecated, because it was designed in 2011 before OpenType fixed new rules in 2016 for the Myanmar script, and it has not been maintained at all, see https://code.google.com/archive/p/tharlon-font/downloads and issues listed on https://code.google.com/archive/p/tharlon-font/issues since 2015, but never corrected: That old Google project has been archived because it was not maintained). Tharlon was based on the preliminary "mymr" specification for OpenType, and OpenType has deprecated and strongly discouraged its use. New OpenType fonts use the "mym2" specification.

For the Myanmar script, please use "Noto Sans Myanmar" instead. "Tharlon" is even worse than "Myanmar Text" provided in Windows (at least version 1.10 since Windows 8, now it is at version 1.20 with Windows 11; windows 7 was initially providing version 1.00 which was also based on the old/deprecated "mymr" OpenType specification, but I don't know if Microsoft has provided updates to that font for Windows 7 users, given that it no longer supports that OS since many years) and cannot be a "safe replacement" to the "Myanmar Text" font. Verdy p (talk) 10:54, 27 May 2023 (UTC)

Tharlon has been part of ULS 2012 and was last updated in 2013.
Currently it's enabled by default for `my` so I would not remove it without clear support from the affected users. Nike (talk) 08:58, 30 May 2023 (UTC)
This is still a problem. It was not designed for Myanmar OpenType "mymr" and its use is officially discouraged and permanently archived since long by Google Fonts. It has not been maintained at all even if it was installed by Wikimedia in 2013, it was still the old broken version of 2011 (which was then in alpha stage) that breaks Latin (because of its fake non-Unicode character mappings, and missing *required* features for OpenType that was defined with "mym2" script rules, where the initial "mymr" specification of 2010 was demonstrated to be broken and was rewritten in 2016). Google Fonts has followed the developpement in "Noto Sans Myanmar" instead. "Tharlon" should not be used at all, not even in ULS in Wikimedia projects, even if it works, partially, but only in pure simple Burmese texts (and even Myanmar linguistic authorities discourages its use, they developped their own font and made it work with "mym2" rules that they helped to define to fix the broken "mymr" rules that were in early OpenType specifications of 2010), and causes numerous isues elsewhere and no one supports it since 12 years. But as "Tharlon" was opensourced, it may eventually be fixed by Wikimedia if they wants to keep it, but they should drop the broken Latin mappings, and they should make sure to not force Myanmar pages to load that font, to override any other conforming font. Verdy p (talk) 09:06, 30 May 2023 (UTC)

FuzzyBot doesn't seem to help CeJS update anymore?

Not sure what's going wrong, FuzzyBot seems to have stopped updating CeJS since last week after this commit? I wonder if someone can help to solve the problem? Kanashimi (talk) 21:16, 23 May 2023 (UTC)

Seems to be working fine. There was update on May 25th. Sometimes updates may be skipped if there isn't any changes or incoming changes haven't been processed. Nike (talk) 08:59, 30 May 2023 (UTC)
Ok. Thank you. Kanashimi (talk) 07:30, 31 May 2023 (UTC)
Retrieved from "https://translatewiki.net/w/i.php?title=Support/Archive/2023/05&oldid=11665507"