Support

From translatewiki.net
Jump to navigation Jump to search
NoteProblems? Questions? Suggestions? Write your message below. — See also the FAQ or try to catch us in IRC.

Your request has been forgotten? Feel free to post a reply to bump the thread to the top. Very old threads have been archived.
(The thread summarization feature is broken, see: Phab:T245109)

Contents

Thread titleRepliesLast modified
Problematic edits of Verdy_p (again)710:25, 23 April 2021
How I can rename my account?810:11, 23 April 2021
Tarandine - false not update messages008:40, 23 April 2021
Rename Javanese Wikipedia mainpage from "Tepas" to "Pendhapa"005:20, 23 April 2021
[TWN] [Waymarked Trails] non-working link for their help pages in Group descriptions006:53, 22 April 2021
Problems for Ajapaik in pms306:41, 22 April 2021
Encyclopedia of Life: no export since 29 August 2019308:26, 21 April 2021
Missing space after punctuation in Phabricator:phabricator_ext-core-*/en105:09, 21 April 2021
Phabricator:phabricator-config-f1fa5528f9aeb0d9/en104:48, 21 April 2021
Account problem104:27, 21 April 2021
MediaWiki:Contenttransfer-too-many-pages-warning/en and various typos in today's Mediawiki package for content transfers and page merges109:42, 15 April 2021
MediaWiki:Bs-insertmagic-nocontentconvert/en: is "phase" a typo for "phrase" ?106:45, 15 April 2021
Problem saving links with hardcoded diacritics via the translation interface417:22, 14 April 2021
North-Central Dargwa (or Dargin) language [dar]123:17, 12 April 2021
Not allowed to translate a message114:47, 9 April 2021
TheWikipediaLibrary - json-based i18n files in addition to existing gettext1014:48, 7 April 2021
Activate new language-code: Aruban Papiamento [pap-AW]520:50, 3 April 2021
Please add the Kom language [bkm]114:25, 1 April 2021
New project : docs.python.org/fr/110:49, 31 March 2021
Is translatewiki still updating every Monday and Thursday?215:31, 30 March 2021
First page
First page
Previous page
Previous page
Last page
Last page

Problematic edits of Verdy_p (again)

Hello,

While Verdy_p did a lot of good edit, he sometimes goes totally off rail and in this case it's seems impossible to talk with him. He has been blocked for this for a month earlier this year and now he is edit warring again...

This time, this is even more ridiculous than usual, he is basically at an OS what is an OS and why the terms everybody everywhere on Mediawiki use for decade is wrong: Thread:User_talk:Verdy_p/MediaWiki:Flow-history-action-suppress-post/fr. @Jules78120: is one of the few people (5-ish) in the world would will see these messages and he use them frequently but Verdy_p still persist to think is right.

This is very disruptive. On consequence is that we have to put local messages on Wikimedia Project (and other wikis) because of these unconsensual changes. This make Translatewiki worthless and look bad to wiki communities.

I don't know what could be the solution. Verdy_p raised a good point when he said (in a earlier dicussion) that the context is not always clear and the system should be improved. But even then, this explain the first error he made not why he continues to edit war after he was warned that this is an error. I'll let admin decides (meanwhile, I'm still staying far away from Translatewiki and cleaning local messages to have correct translations).

Cheers,

VIGNERON (talk)09:25, 22 April 2021

I've not edit-warred, even if a user disagreed on some thing, he started to discuss after the fact, and changed his mind several times, using unexpected brutal comments. And it's definitely NOT "impossible to discuss with me".

I've proposed several things, and again he continues with the lack of politeness. I've discussed fairly (and the prior blocking you invoke against me was also unfair, disregarding as well all efforts I made to negociate calmly and discussing the various options: this blocking was appealed but in fact only this blocking unfairly blocked any kind of discussion, so it was only me that was in the impossibilty to discuss, but not because of any action I did myself).

It is a fact that the existing old translation was NEVER reviewed before by anyone, and reviewing is a full part of Transltewiki.net: if this causes any conflicts, there's no need to forget politeness and discussions should start allowing anyone to give his arguments and propose solutions and comparing them.

I was once again absolutely not "off rails" like you state here. This was fully in respect of the TWN site (for an extension which is also not targetting specifically the French Wikipedia where it is seldomly used just by few users, and even less users having the privileges where confusion is possible: there's no confusion at all for the vast majority of users).

So your statement that this could be "very disruptive" is unfair: for whom? very few admins in French Wikipedia or millions of users not having these privileges but that are exposed with incoherent translation with Flow's options? It's a fact as well that the choices made in English are using another kind of confusion ("delete" vs. "suppress", two different admin optins), which does not help the translations. A single user made an unreviewed choice 3 years ago and tyhat problem was not even reported before. Still, coherence of translations in TWN are a documented goal (that Flow somewhat violates, and the "solution" proposed 3 years ago only in French does not match what was currently used with English that at least avoided breaking the MediaWiki UI coherence for the vast majority of users).

My change in november was part of a normal review for coherence, using the doc provided by Flow authors themselves and visible in the "/qqq" page: this what guided me during the review.

And you are wrong when you say that I changed something used since very long: in fact I just used and respected the translation made since very long in the Mediawiki UI (Flow changed it only in 2017 when it started but this caused an unreported and undiscussed confusion since then in all languages, including English but only for or those very few users having sysop or oversight rights and that should be better trained than the vast majority of users seeing and using "hide" in English, "masquer" in French, without any privilege, but jsut as theur own personal navigation preferences).

I feel that your reaction is very stange: anyone that contributes a lot in TWN will fall into some disagreements with a few users that contribute rarely. This is completely unavoidable. But there's a way to discuss that, and I used that, without forgetting politeness like what your contact did instantly.

Why using such procedure now instead of solving the existing problem created recently only in Flow (2017 for the initial beta tests, but even in French Wikipedia this started being used later in very few user pages) ?

The only real problem is the incoherence (in French only) for not translating "hide" as "masquer" (like it is in MediaWiki since very long) for ALL users. The very few oversighters (on French Wikipedia) should use their own translation for their specific administrative actions without disrupting millions users exposed now with an incoherent translation that does not even follow the **existing** documentation (the "/qqq" page with its links, that I fully respected during a basic review that was not performed by anyone since the initial submission by a single user).

Verdy p (talk)09:39, 22 April 2021

The history of a message like https://translatewiki.net/w/i.php?title=MediaWiki:Flow-moderation-confirm-hide-post/fr&action=history is textbook editwar.

« I've proposed several things », changing a message without talking to anyone before and then reverting everyone who disagree with you is not "proposing".

The first replacement of « masquer » by « cacher » on  MediaWiki:Flow-moderation-confirm-hide-post/fr was done by @Arkanosis: in 2014, which is not 3 years ago and that can count as some sort of review.

If you distord such plain and obivous fact, how can we even start to have a real discussion?

@Nemo bis and Nike: about the « prior blocking » being « unfair ». You had 7 blocks here, 7 blocks on fr.wp, 1 block on en.wp (in fine, almost always for the same reason: edit waring) and you still don't understand... It has also been said countless time to stop dumping long blob of text, this is not helpful and clearly you don't listen to other editors.

Ping @admins: at the very least, what do you think of instoring a 0RR to stop the editwar?

VIGNERON (talk)11:34, 22 April 2021

I have not seen any change in 2014... Flow was not even existing at that time (at least not in fr.wikipedia as it was possibly just in alpha and not deployable except for custom tests). The "evidence" that was given to me (in the discussion) was effectively pointing to 2017... Still Mediawiki exists since much longer time, and the term chosen for Mediawiki for the non-adminsitrative term "hide" dates since longer, as well as the choice decided to use "masquer".

As well the docuumentation in "/qqq" for that message was pointing to a common terminology supposed to unify the term hide with the MediaWiki usage (which was broken only in French and fiors the first time in 2017 from the evidence given, and not discussed anywhere by its submitter, just because he was confused by the terms used in English for the two adminsitrative options "delete" and "suppressed")

Once again when I just reviewed that term in Flow (which was never reviewed before), this was clearly not an edit war, but the instant reaction from another user was excessive, and largely abusing the rules of politeness. I can understand the irritation, but this should have lead to discussing the problem, instead of once again accusing me for things done that respected the common rules and guidelines.

I've not lied, I've not changed my mind though, but this does not mean that my polite talk is means that it's "impossible" to talk with me (at first, that user that complins now, had not initiated any talk, he just expressed his irritation in offensive terms, and once he started talking and I replied calmly, he complained again. Who is refusing to talk? If it's "impossible" to talk it's not my fault, and in fast it has always been possible.

I've iven a rationale, may be you don't accept it, but it can be evaluated, and there's efectively a problem. And no need to use bird's names. I contribute a lot and let a lot of existing translations pass (including many changes). Very few terms will cause a discussion because there's a disagreement or misunderstanding, but no need to use bad tone. I've made my best, that user also tried his best at that time, without seeing the problem. I'm only more exposed to such conflict because I contribute a lot, and I take care of remembering the past as much as possible (it may happen that I can't remember everything in the past, notably if there were old discussions made years ago, without leaving any comment or documentation).

The document I used was the "/qqq" page, but the complaining user commented with "which doc?" meaning that he had not even read it, even if it was very visible in the normal UI of TWN. That "/qqq" page was the first evident source and the main cause of this unification of common terminology already used and decided since long in MediaWiki core messages.

"I've proposed several things": yes, see the talk thread that was initiated by the complainer and linked in his edit summary. He initiated the talk, I replied promptly and calmly (without using the unpolite tone he used and repeated later), so where is it "impossible" to talk with me?

Verdy p (talk)12:24, 22 April 2021

Please keep you answer short and it also wouldn't hurt to know what you are talking about (a simple look at the history shows the message exist since 2013 and the term here is used by Flow - now known as Structured Discussions - but not from Flow, it is older and used in other older messages).

Your first edit was indeed not an edit war and could be seen as a simple honest good-faith mistake, the following reverts are clearly an unconstructive edit war. Other people shouldn't have to start the discusion, you are responsible for your edits ; when reverted, the usual and correct wiki way is to start a discussion, not to revert (as you have been told multiple times already).

For the MediaWiki:Flow-moderation-confirm-hide-post/qqq, did you really read it yourself? by putting the same translation "Masquer" on two different message use in the same context,  MediaWiki:Flow-moderation-confirm-hide-post/fr and  MediaWiki:Flow-moderation-confirm-suppress-post/fr, you obviously less the interface less clear.

VIGNERON (talk)13:14, 22 April 2021
 

Bien sûr que j'ai lu la doc "/qqq" et j'ai justement veillé à éviter toute confusion, il n'y avait PAS (et il n'y a jamais eu) la même traduction "masquer" dans les deux messages (quelque soit le contexte d'utilisation).

Et bien sûr que c'était PLUS CLAIR :

  • "hide"="masquer" pour l'action d'interface de navigation donnée à tout le monde (sans privilège et sans conséquence pour les autres visiteurs ou utilisateur, et uniformément conforme à l'interface de MediaWiki)
  • "delete"="supprimer" (uniformément conforme à l'interface de Mediawiki, même si cette option dans Flow n'est disponible qu'aux "sysops")
  • "suppress" (problématique en anglais aussi, disponible aux seuls "oversighters", une poignée): c'est là le désaccord car les premiers traducteurs y ont mis "masquer", qui ajoutait de la confusion non plus avec la deuxième option quasi-synonyme pour sysops comme en anglais, mais a perturbé les millions d'utilisateurs de Mediawiki, car la première option a été unilatéralement remplacée avec "cacher", quasi-synonyme sans ajouter aucune clarté réelle, et sans dire non plus dans l'option 3 que c'était non pas l'option 1 commune de navigation personnelle sans privilège mais bien une action de modération administrative.

La doc "/qqq" notamment inclue une liste de termes "identical" (ou supposés comme tels et voulus ainsi par les auteurs de Flow): il suffit de la dérouler (justement avec un lien "afficher/masquer" basculable !) pour voir qu'en français ce n'était pas pour Flow le terme attendu et utilisé depuis longtemps (et dans cette liste pour l'interface de Mediawiki il y a a eu déjà diverses autres unifications de "cacher" vers "masquer": Flow ne devrait pas faire exception et c'est à lui de s'adapter dans ses autres options administratives, en ajoutant une précision claire)

On peut ne pas être d'accord avec ce que je désigne comme "modération" pourtant c'en est une, le terme seuil d'indiquant pas la raison de la modération, mais le fait de rendre invisible à tout le monde (et pas juste soi-même) de façon contraignante (selon une politique donnée, qui peut être de protéger la vie privée mais peut être toute autre raison justifiée par une politique en vigueur ou une obligation légale que le site doit respecter ou qui lui est imposée par une autre autorité plus forte).

Verdy p (talk)13:30, 22 April 2021

« il n'y avait PAS (et il n'y a jamais eu) la même traduction "masquer" dans les deux messages (quelque soit le contexte d'utilisation) » : c'est faux.

C'est précisément parce que dans l'interface des historiques Flow il y avait deux liens « masquer » que je suis venu corriger ici. Et c'est bien vous qui avez introduit cette erreur. MediaWiki:Flow-history-action-suppress-post/fr indiquait (à raison) « masquer » et MediaWiki:Flow-history-action-hide-post/fr indiquait aussi « masquer » depuis votre revert de novembre 2020. Donc soit vous êtes totalement de mauvaise foi, soit vous ne savez pas consulter des historiques.

Quant au reste de votre argumentaire, ça fait dix fois que je vous explique que « masquer » est un terme systématiquement utilisé pour décrire des actions admins ou OS (masquage léger/masquage lourd, cf. [1] ou [2]), donc ne doit évidemment pas être utilisé pour l'action hide qui est une action accessible à tout le monde. C'est pour cette raison qu'Arkanosis ([3], [4], [5], etc.) ou Kvardek du ([6]) avaient corrigé.

Si l'erreur initiale est compréhensible, il est tout de même incroyable que vous me révoquiez puis que vous persistiez dans l'erreur.

Jules* (talk)10:25, 23 April 2021
 
 
 
 

Thanks for the warning, blocked again. (I forgot to disable the autoblock, but for this length it doesn't matter much.)

Nemo (talk)13:32, 22 April 2021
 

How I can rename my account?

Hi. I am the user NikosLikomitros, from Greek Wikipedia. I had the same name with my Translatewiki account until 26 December 2019, when I was renamed, however I still use the old name in Translatewiki. Can someone rename my account to NikosLikomitros, or direct me to the correct page if we file the requests somewhere else?

Nikosgranturismogt (talk)17:54, 4 December 2020

Done Done

Raymond17:38, 5 December 2020

Hi @Raymond:. Could you rename my account in User:Jules* please, to match my Wikimedia accounts ([1])? Thank you very much.

Jules78120 (talk)19:01, 21 December 2020
 

@Raymond: Thank you for your quick response.

NikosLikomitros (talk)23:19, 23 December 2020

Hi NikosLikomitros, I am not sure if I understand: Do you request another username change? to "User:Jules*" now?

Raymond13:35, 24 December 2020

Hi @Raymond:. No, I'm a different user, I'm not NikosLikomitros. I'm user:Jules78120 I would like to rename my username to user:Jules* as "Jules*" is the username I use on Wikimedia projects. Is that possible, please?

Jules78120 (talk)09:50, 21 April 2021

I think that Nikos (alias "Nikosgranturismo" or "Nikosgranturismogt" or "Jules72120" or "Jules*": not clear!) wants to restore the asterisk at end of his preferred account name. But may be there are issues on Translatewiki.net with such asterisks, e.g. for tracking changes, or exporting data in various formats (not just for Wikimedia). But he made two different demands, and he should be consistant in his renaming demands (repeated now and alrady in the past!).

MediaWiki accepts the ASCII asterisk in their page names (including user pages, but this is an artefact as the real intend was to allow it in article names), but this is not true for all tools (not even in all tools used by Wikimedia, e.g. in Phabricator, or IRC, or Toollabs, or other CMS like Wordpress). Asterisks are not part of acceptable identifiers in programming language according to CLDR and Unicode character properties; they are rejected in many internet protocols (e.g. in the DNS for the start of authority and in the Whois database for domain owners). The same is true in many filesytems and applies to the question mark (?) which is also problematic. Choosing such user names with ASCII asterisks or question-marks in Wikimedia is definitely not recommended (even if it still works for now, there's a risk that in the future such possiblity will be refused and all these users will have to choose a better name, notably if this causes damaging security issues).

But Nikos should be aware that Translatewiki.net is not bound to Wikimedia rules and local user accounts are completely independant (and not linked with Wikimedia SUL for example). Renaming an account cannot be honored from an account that the user cannot authenticate with (this could be used for abuses and defamation of unrelated and legimate users, in,cluding in personal attacks to unfairly get someone being administratively blocked). Renaming may be needed in some cases for anonymization, in which case the demanding user will not be able to specify the anonymized account witll be be very generic with a common prefix and a random pattern at end (such as "Anonymous-9823141"). Renaming an account is costly in terms ofresources in the server as it involves global searches and edits in many pages, and there's not even a warranty that this will succeed everywhere (including many existing third-party mirrors).

There's then NO assumption (or requirement) that any account name will match between TWN and Wikimedia (and no reason to unlink/rename one account from one domain or another, if they were validly created and are still in use (this is also still true for many legacy accounts in Wikimedia that were registered separately with the same account name but by different users on different wikis, before SUL was implemented and deployed: such renaming requests are also rejected by Wikimedia if their existing owners are legitimate, and active or have made many of useful contributions, because this is required for respecting their respective copyrights and authorship).

No user should assume they have an universal right to reserve an account name on various domains they may want to subscribe and use separately in the future (or never...). However, as as the desired account name is available (and not used by any link, don't just look at the existence of the user page), users may just take these accounts themselves (with a new registration after logging off) and then alter their previous account using a local redirect (they can legitimately alter their previous user page if they logoff and logon again with their previous account). Such thing must not be abused: users should limit the number of account names they need and the only ultimate right is just the legitimate right to anonymize themself to protect their privacy, or the need to work with a separate identity to match a specific role (e.g. as an approved worker in an organization, or for operating a bot separately from the personal human interactions). This should not be used at all to avoid a blocking, or falsify votes: account creations by the same user should be limited

Verdy p (talk)11:05, 21 April 2021
 

Hi Jules*, I have done the requested rename now. And excuse my mix-up with User:NikosLikomitros. For the future please open for every request a new thread. Thanks.

Raymond17:48, 22 April 2021
 
 
 
 
 

Tarandine - false not update messages

In group list about Tarandine localization, I see (since last March) some groups with not update percentage, but when I try to fix the messages I've NO MESSAGE TO UPDATE

Group list.png

Please fix this error

Joe Taras (talk)08:40, 23 April 2021

Rename Javanese Wikipedia mainpage from "Tepas" to "Pendhapa"

Since I cannot edit this page, I'm requesting changing the Javanese Wikipedia mainpage from "Tepas" to "Pendhapa" per this proposal. If possible, could anyone apply this page as the main page without the title text (like the usual main page)? Thank you!

NoiX180 (talk)05:11, 23 April 2021

[TWN] [Waymarked Trails] non-working link for their help pages in Group descriptions

The current English source (Translations:Group descriptions/waymarked-trails-help/en) indicates a non-working link (http://waymarkedtrails.org/help/about) to its supposed help pages.

However such help pages do not exist as they are actually hosted on several distinct subdomains (and are using HTTPS, not HTTP).

This message is part of the translatable page Group descriptions, listing and summarizing all translation projects currently supported in Translatewiki.net (this page is not managed by Waymarked Trails authors themselves).

The actual help pages are on:

I did not find any general index page on waymarkedtrails.org (whose HTTP site redirects instantly to HTTPS). In all cases, the current link is misleading and just displays a 404 (Page not found) and does not go display any info or link, and does not redirect anywhere else.

If you don't want to include the previous (corrected) list of working links, may be you can just link the base website (https//waymarkedtrails.org/) where you can select the subtopic: then below the map, there's a [i] button at the bottom linking to appropriate info and help pages (this button goes to one of the links listed above, depending on the selected subdomain). But may be there's a specific help page for all Translating:Waymarked Trails.

Do we even need this line containign such link(s) in the Group descriptions page, shouldn't it be on Translating:Waymarked Trails ?

Verdy p (talk)15:55, 21 April 2021

Problems for Ajapaik in pms

Hi! There are still 10 messages of Ajapaik that need to be translated in pms. However, it seems impossible to do that. What is the problem?

Borichèt (talk)06:41, 16 April 2021
Abijeet Patro (talk)04:56, 21 April 2021

The fact is that when I try to translate the ten missing strings, I get the messge: Translation to this language is disabled.

Borichèt (talk)06:43, 21 April 2021

You have been able to save one of those translations, thanks a lot! But I still have the same issue with the others... I can't understand why.

Borichèt (talk)06:41, 22 April 2021
 
 
 

Encyclopedia of Life: no export since 29 August 2019

Edited by author.
Last edit: 08:26, 21 April 2021

Is the "Encyclopedia of Life" (EOL) project still actively maintained ? Or just dormant (waiting for further developments). There's not been any commit in their repository since 29 August 2019:

https://github.com/EOL/eol/commits?author=translatewiki

But in fact there's not been any other commit for any other part of their project in their repository (and no progress at all in their online bug reports). As well the online version of the site seems to be frozen from the same date.

If it is maintained now by another administrator, using another repository, or going to become a closed project, or waiting for a new admin, we should be informed.

Verdy p (talk)19:17, 26 March 2021

Hi Verdy p,

Changes to Encyclopedia of Life are pushed to this repository: https://github.com/EOL/eol_website

Regards,

Abijeet Patro (talk)10:22, 31 March 2021

Then the projet portal gives the wrong repository if it has changed. It needs to be updated.

Verdy p (talk)12:44, 1 April 2021

I see you have done that, thanks.

Regards,

Abijeet Patro (talk)04:08, 21 April 2021
 
 
 

Missing space after punctuation in Phabricator:phabricator_ext-core-*/en

Most probably, there where newlines between sentences in the original source code, that were incorrectly stripped while joining lines, instead of being converted to at least a whitespace.

Another typo in the same "phabricator_ext-core" package:

Verdy p (talk)09:25, 14 April 2021

Account problem

Hello, is there an option to regain access to my account User:Spacebirdy. I can verify who I am.

Password reset did not work, I did not get a mail nor in my spamfolder.

Kind thanks in advance, --TheSpacebirdy(talk): I am Spacebirdy 11:22, 8 April 2021 (UTC)

TheSpacebirdy(talk): I am Spacebirdy11:22, 8 April 2021

I've also requested a password reset for the user. Let me know if you still don't receive an email.

Regards,

Abijeet Patro (talk)04:27, 21 April 2021
 

MediaWiki:Contenttransfer-too-many-pages-warning/en and various typos in today's Mediawiki package for content transfers and page merges

Dummy repetitions of the word "pages" in the source English message (inside and outside the PLURAL tags). And other typos in "Contenttransfer" (all are on new resources changed or created in the last few hours):

See:

Verdy p (talk)15:34, 14 April 2021
  • For ContentTransfer: Gerrit:679637
  • For MergeArticle: Developer informed per e-mail.
Raymond06:35, 15 April 2021
 

The word "phase" present in the English source (as well as in the "/qqq" page where it was probably copy-pasted) may actually be probably a typo, used instead of "phrase". I don't see any case where "phase" would make sense for the automated conversion of language variants (i.e. actually characters and phrases) by MediaWiki...

Verdy p (talk)23:13, 12 April 2021

Developer informed per e-mail.

Raymond06:45, 15 April 2021
 

Problem saving links with hardcoded diacritics via the translation interface

Hello. I'd like to report a problem when saving links with hardcoded diacritics (č, ž, š) via the translation interface. The error provided was as follows: "The following parameter is unknown: %8". I have been able to save the link https://sl.wikipedia.org/wiki/Matemati%C4%8Dna_konstanta by editing the source of the message directly. The error occurred in Blockly:MATH CONSTANT HELPURL/sl. Should I file a bug on Phabricator? Thank you for your feedback.

Eleassar (talk)12:26, 20 March 2021
Edited by author.
Last edit: 21:05, 3 April 2021

URLs in basic format are not "hardcoded", they are usually "url-encoded", by transformating each byte of UTF-8 sequences for non-ASCII characters into 3 ASCII bytes ("%nn" in hexadecimal). The leading byte is URL-encoded in "%C2".."%FD", the following 1 to 3 trailing byte(s) are in "%80".."%BF" (the number of encoded trailing bytes depends on the value of the encoded leading byte), so this bug affects any Unicode character that contain any trailing bytes URL-encoded in "%80".."%9F", i.e. one half of all non-ASCII characters, because the Translatewiki.net's UI incorrectly assumes that "%80".."%89", "%90".."%99" (or "%8" and "%9" for actual bytes URL-encoded as "%8A".."%8F" or "%9A".."%9F") are an incomplete scanf/printf placeholder, not correctly terminated by a valid type/format letter (so yes this is a serious bug)

When trailing bytes are in "%A0" .. "%BF", this bug does not occur because "%A" or "%B", in capitals, are not recognized as valid placeholders for C/C++, but the bug would occur if these bytes were encoded using non-standard lowercase in "%a0".."%bf" (because "%a" and "%b" could eventually be placeholders in some C/C++ libraries using extended scanf/printf formatters).

Translatewiki.net actually does not properly check if theses are valid C/C++ placefolder for print/scanf. It does not even know that the message will be used with a C/C++ library, and it also supposes this could be placeholders for other languages (such as DOS-Command or NT-CMD shell variables, or libraries for Java, Javascript, PHP, Python...).

Here you tried "%8D" which superficially looks like a printf/scanf placeholder for a format of length 8 but unknown type/format letter "D"; as this is not recognized, then TranslateWiki assumes this could be also a basic "%n" placeholder for another syntax (a shell syntax for command.com/cmd.exe? or some other programming language of library), and errs because there's no such "%8" placeholder in the original string to translate. What Translatewiki.net does is just making superficial guesses, with frequently false assumptions.

  • One possible workaround could be to link to another redirecting article that does not use these characters in their title (e.g. redirecting the English title).
  • Another alternative would be to not URL-encode non-ASCII characters in the URL, using the IRI syntax supported by modern browsers (and supported also by the MediaWiki parser).
  • You've found the wordaround using the MediaWiki editor instead of the Translate UI (but note that even if you've edited it there, the text cannot be validated in the "review" UI of TranslateWiki, or will resurrect if one needs to point to another URL on the target wiki).

This is a bug of the Translate interface itself: the solution would be to mark the resource to translate as not using the Mediawiki syntax (if this is the case) and containing no C/C++ "printf/scanf-like" placeholder when importing the resource on Translatewiki.net, so that its UI won't perform an incorrect validation check.

As far as I know, the UI of TranslateWiki.net still does not support such flagging (unlike what other common UIs for translations of .po/.pot files for gettext) and just makes some "magic" guess of the format used, assuming it is either using the Mediawiki syntax (where such URL-encoding of URLs is not needed, but where "{}" and "[]" are special-cased for MediaWiki's parser, as well as "$name" for Translatewiki's syntax itself and supported in the Mediawiki API internal libraries, and a few other syntaxes) or the placeholders in C/C++ "printf/scanf" format strings.

Translatewiki.net should not perform such magic guess of the expected format. It creates false positives and does not properly validate all what may be needed for projects. It should support resource-flagging like in .po/.pot translation tools (where the uncompiled ".po" format uses special comment-lines starting by "#," before the resource texts starting by "msgid" or "msgstr"), using some metadata separated from the original string, possibly stored in the "/qqq" doc subpage, or in a dedicated "/qqx" subpage, or using some hidden tag in the source page (like TWN already does when prepending hidden "!!FUZZY" markers in translated subpages that need updates).
I would suggest prepending "!!FORMAT(...)" or "!!{...}" markers is source pages to store that metadata, and possibly as well in the translated pages to make sure that these special markers are in sync with the original).
As well, a project should be able to store such global metadata for their whole message group (to provide some defaults that could be overriden in specific resources using the special marker), notably the programming language that will use these resources, so it will know if printf/scanf format strings are really needed, or if Mediawiki or HTML syntax is expected. This means creating a special page for each message group, containing the group description, contact info, supported formats (including supported plural forms), URL to help/support pages, URLs to their bug tracker and relevant discussions or terminologies for specific languages...
These changes in TWN would make this wiki more universal to better support more projects. The alternative for these projects are to use online translation tools other than Translatewiki.net (most of them are built for .po resources with gettext)...

The alternative would be for Blockly to accept this string in IRI format, natively in UTF-8 (like in the address bar of modern web browsers, or in the Mediawiki parser), documenting that the URL should not be URL-encoded (this would require Blockly to URL-encode that IRI itself, either in its runtime code or during the import of translated resources from TWN to their code repository) and documenting that info in the "/qqq" doc subpage of TranslateWiki.net. However that last alternative requires involving Blockly developers, notifying them, and make them aware of what they can do when importing/exporting their project with Translatewiki.net (only these developers can instruct translators about what they can do).

Verdy p (talk)19:32, 20 March 2021

Hi, Verdy. Thank you a lot for your detailed and clear explanation. The last option would certainly be best but would require someone with the relevant technical knowledge to communicate with developers. Would you be willing to take this on? Otherwise, I'll ask a colleague or will try to do it myself. For the time being, I'm staying with the workaround. --Eleassar (talk) 08:14, 21 March 2021 (UTC)

Eleassar (talk)08:14, 21 March 2021

Feel free to link this talk thread. I would be pleased to see such suggestions implemtend somewhere for improving Translatewiki.net and better support the hosted projects with better communications and reporting with translators, and improved checking and validation of translations.

Verdy p (talk)22:32, 3 April 2021
 
 

I have disabled variables check on this message.

Nike (talk)17:22, 14 April 2021
 

North-Central Dargwa (or Dargin) language [dar]

Hello, here is the Incubator of, as I understood, literary Dargin (Dargwa) language, with the "dar" ISO code. But I couldn't find this language on Translatewiki. I also ask to enable the ability to translate the interface of the Tsudakhar language (the north-central group of Dargin languages). I believe that it has no ISO code, so it could be "dar-tsud" or "dar-cud".

Soul Train (talk)15:38, 12 April 2021

North-Central Dargwa is in Translatewiki./net, but may need to be opened for work: Portal:Dar, and I think it is already appropriate for your demand, even if the "babelbox" incorrectly abbreviates the language name to just "Dargwa", the ISO 639-3 code [dar] is already for the north-central group of Dargwa (or Dargin).

For such dialectal division (actually you propose a dialect within North-Central Dargwa), you need at least 5-letters of extension (and the extension registered in the IANA database, such as [dar-tsuda] or [dar-cudar]) : effectively, all "extang" subtags (3-letters after the primary language subtag) are permanently reserved in BCP 47, and since the publication the reform in RFC 4646, they are deprecated by the publication of ISO 639-3, which stil considers Dargwa [dar] as a single language (but still not as a macrolanguage, because it contains no other single language).

As long as the dialect group is not in the IANA database, you would have to use a private-use extension (starting by "-x-", followed by another subtag using 1 to 8 letters or digits), such as [dar-x-tsuda] or [dar-x-cudar].

So certainly not "dar-tsud", nor "dar-cud", per BCP 47 encoding rules.

Look at: https://glottolog.org/resource/languoid/id/darg1241 (and related entries in The Linguist List), which list these dialect groups (Glottlog assigns its own private-use codes for language groups or dialects, using 4 letters followed by a number; but they are distinct from ISO 639 codes and BCP 47 tags):

  • Megeb
  • North Dargwa
    • Cudaxar (or Tsudakhar) : this is probably the dialect you are speaking about...
    • Gapshin-Butrin
    • Kadarskij
    • Muirin
      • Dejbuk
      • Xarbuk
    • Nuclear North Dargwa
      • Mugin
      • Murego-Gubden
      • Upper Mulebki
      • Aqusha-Uraxi (or Uraxa-Axusha)
        • Akusha (or Akkhusha, Urakha-Akhush, Urkarax)
        • Uraxa

You are refering to the North and Central group of Dargwa dialects, which is exactly what [dar] itself encodes as a single language. Your reference to "Tsudakhar" is just one possible alternate name of the language, used when focusing just on one of its dialects (and not the whole group, i.e. [dar] itself). So your request seems quite confusive.

The "South Dargwa" group is not part of [dar] and refers to two other languages with their own separate codes (in Glottolog and the linguist list, even if they still don't have an ISO 639-3 code for them). South Dargwa languages are still not encoded in ISO 639, most probably due to lack of studies and litterature about them (very few references found in Glottolog and the Lingist list, all quite recent, with only one in 2003, the next one in 2012, the first dictionary Southwestern Dargwa having been published only in 2017 by a single author for the "Sanzhi-Icari" dialect which is apparently its most common one buyt possibly partly covering some other dialects; no litterature is found for the 2nd South Dargwa language, i.e. Kajtak, also not encoded in ISO 639-3).

It is highly probable that South Dargwa languages speakers are/were already using North-Central Dargwa (Cyrillic script) as a lingua franca or for administrative/legal purposes in Dagestan (or some other bordering languages or scripts, like Azeri with the Latin script, or Dagestan and Russian with the Cyrillic script, or Georgian with Georgian script, or the Arabic script for religious purposes), or that informal writings were developed but not widely published, using some phonetic adaptation were needed).
Verdy p (talk)18:39, 12 April 2021
 

Not allowed to translate a message

I tried to translate (edit a translation) a message in the MediaWikicore message group but i get this message: "You do not have permission to edit this page because it contains raw HTML which can be modified to affect all visitors." So how do i translate it?

yardom78 (talk)12:40, 9 April 2021

This is to prevent insertion of malicious code (notably rogue links to bad websites, or dangerous javascript that could steal data from the user).

Usually this occurs when the resource to translate contain raw HTML and the HTML elements or some of its attributes are not completely safe, or is not checked automatically as being safe, or uses an uncommon encoding and is not fully plain-text or the encoding could be used to bypass a HTML security).

You need to specify the link to the message you want to translate, and the language code.

Then submit your translation proposal in a thread posted here, asking for an admininstrator to submit it for you. Your message will also help project maintainers find a better solution to make these resources more easily translatable without the possible security issue. In some projects, the doc page ("/qqq") shows a contact address or link that you can use (possibly on a repository or bug tracker).

Verdy p (talk)14:47, 9 April 2021
 

TheWikipediaLibrary - json-based i18n files in addition to existing gettext

Hi there,

We're working to address a longstanding issue that precluded some of our content from being translatable via translatewiki. We're moving messages from the database into json files over the course of a few PRs, with the idea that these would be picked up by translatewiki. Our first take on this is to do a json file per message type and language, and we've started with the descriptions of our partners who provide resources for the library. You can see here that we've got the descriptions for all partners together in a file for each language. If we move forward with this, we'll add new files for other fields as we take that content out of the database. Before we proceed any further, I'd like to check in to see if this approach is workable on your end, or if we need to organize the data differently. Here's our 1st PR to make this move, so you can see what it looks like currently: https://github.com/WikipediaLibrary/TWLight/pull/654

Feel free to ignore the python, which does the job of extracting the info and creating those initial json files, and just focus on the json.

Feedback is welcome!

Jsn.sherman (talk)16:47, 30 March 2021

Thanks a lot! JSON is generally easier to manage than PO.

One issue I immediately see is that you output non-ASCII characters as escapes, such as "101_short_description": "<p>\u0627\u0644\u0645\u0646\u0647\u0644", etc. According to the convention documented at mw:Localisation file format, it's preferable to use the actual letters and not escapes. Will it be possible to do it? Since humans won't have to deal with these files very often, it's probably not a blocker, although User:Abijeet Patro and User:Nike should correct me if I'm wrong. That said, humans may have to deal with it; for example, sometimes it's too difficult to find things in translatewiki itself and it's more convenient to grep through the source.

Moreover, perhaps you don't need to convert the translated files at all: maybe it will be enough to add en.json and qqq.json and let the translatewiki import/export scripts generate the JSON files with the translations.

Amir E. Aharoni (talk)16:58, 30 March 2021

I agree that using plain UTF-8 would be better (the "\uNNNN" escape can cause problems, as it requires encoding pairs with surrogates from every character in Supplementary planes, and the convention is not universal, as some tools will require the long form "\U00NNNNNN" instead.

As well it is overlong and some tools may not accept leading zeroes, generating ambiguities, unless they use a strictly conforming JSON parser). No such problem with UTF-8, as the only escapes needed are for quotation marks and backslashes inside actual texts, and some ASCII controls like TAB and NEWLINE: this is much simpler to parse anyway even with only a few ASCII exceptions).

You should ensure that the generated JSON is strictly valid to the JSON standard (and not dependant on the old Javascript implementations that had these caveats). You may eventually be lenient when parsing input JSON, as long as there's not any possible ambiguity.

Verdy p (talk)17:20, 30 March 2021

This is all extremely useful stuff. We should be able to do UTF-8 in our initial output and add a json linter to our CICD process to make sure that we can parse the input.

On the creation of files: It's actually easiest for us to create them all no matter what, but we can update to cull the empty ones. We do have a couple of existing translations currently, so it sounds like the ideal process might be to create qqq, en, and then any translations that we do have?

Jsn.sherman (talk)17:46, 30 March 2021

Hi Jsn.sherman

The JSON structure appears to be good and we should be able to process it on translatewiki.net. It will require a small change on our end to read the new JSON file. This change will also be needed if more JSON files are added in the future. You can also use the banana-i18n format for strings in the JSON.

Could we skip the keys that don't have any definition such as: "24_description", "78_description"? These keys appear to be machine generated, can we assume that these keys will not change?

I see that (almost) all the strings in the English language end with "\n". Can this be added programmatically? It maybe difficult for translators to recognize and add this at the end of every translation that they make.

Regarding creation of the language / translation files, only create the language files for which you have translations. When importing the messages translatewiki.net will take care of reading them.

One more thing, translatewiki.net will add a @metadata key to the JSON file. Example: https://github.com/wikimedia/mediawiki-extensions-TwoColConflict/blob/master/i18n/af.json#L2. I hope that this is not an issue.

Regards,

Abijeet Patro (talk)09:03, 31 March 2021

Yeah, I can see that we need to normalize those trailing newlines. Would stripping them out everywhere (instead of adding them) be a good solution?

We can add that metadata key to start with.

And yes, those keys will not change. We may add new ones over time, but won't change what's there.

Jsn.sherman (talk)14:23, 31 March 2021
 
 
 
 

Opened: https://phabricator.wikimedia.org/T279530 to track this

Regards,

Abijeet Patro (talk)14:36, 7 April 2021

Our team was just discussing this some more today and we realized that we may be able to accommodate the content covered by this change with our existing ugettext workflow. Feel free to de-prioritize this task while we verify. We should know in a week or so. I cross-posted this to the phab task as well.

Jsn.sherman (talk)14:48, 7 April 2021
 
 

Activate new language-code: Aruban Papiamento [pap-AW]

Hi!

I'm active in the Wiki goes Caribbean working group and would like to request another language code for Papiamento. We already facilitate Papiamentu ('pap'), spoken on Bonaire and Curacao, but Papiamento, spoken on Aruba, is slightly different in grammer and spelling. Per my conversation with Amir, I would like to suggest to use 'pap-aw' for this variant of the language.

Please let me know if you have any questions.

Ciell (talk)20:04, 24 February 2021

Done.

Amir E. Aharoni (talk)10:03, 4 March 2021

Hi @Amir, Can you help me find this language on translate wiki?

Ciell (talk)09:03, 29 March 2021

Hmm, for some reason it cannot easily be found in the language selector! I'll try to fix that.

In the meantime, here's a direct link that should work as a start: https://translatewiki.net/wiki/Special:Translate?filter=%21translated&action=translate&language=pap-aw&group=core

This link is for core MediaWiki. You can select other components, such as "Visual Editor" in the project selector on the top right side of the screen.

Amir E. Aharoni (talk)10:34, 29 March 2021

Hi Amir, We seem to have the same problem on Wikidata, the language is not visible yet.

Ciell (talk)16:07, 29 March 2021

Please ask Wikidata developers about it.

Amir E. Aharoni (talk)06:17, 30 March 2021
 
 
 
 
 

Please add the Kom language [bkm]

Hi,

I speak the Kom language of Cameroon, and I'd like to translate MediaWiki into this language.

Thanks!

X-Savitar (talk)11:14, 31 March 2021

This is now enabled!

Welcome!

Amir E. Aharoni (talk)15:31, 31 March 2021
 

New project : docs.python.org/fr/

Hi!

We're translating https://docs.python.org in french since around 2000. After using pottle for a few years, since 2015 we only use git & github to translate.

While it works for us because we're willingly using translation to teach git and contribution to open source software, it does not fit everyone: some would just like to translate.

Please note that other languages translators of docs.python.org use various systems to translate: they're all free to choose their process, and we're not going to force them to change, I hope translatewiki has the ability to choose a set of language to translate to.

We do use `.po` files (it's a Sphinx), it's 53034 entries as of 2021-03, 22879 are translated (~43%), and the repo is public on github: https://github.com/python/python-docs-fr, license is CC0, and it change from time to time, mainly on cpython version bumps (yearly), but contributions to upstream docs can occur daily.

We do have a huge proofreading (grammar, spelling, typos, semantic, ...) step before merging a pull request, I would not like translators to use translatewiki as a way to bypass the proofreading step, but I don't know how it can be "integrated".

What I can imagine is: we could take translation from translatewiki and make them PRs so we can review them, edit them at will, before merging, but it would require our modifications to be pushed back to translatewiki to avoid getting out of sync... I don't know what's possible here.

What do you think?

Mdk (talk)15:01, 27 March 2021

Hi Mdk,

Thanks for your interest in using translatewiki.

The translation system at Translatewiki.net is designed to translate software projects into various languages from the source language but as far as I understand it, you'd like to just allow translations to French for https://github.com/python/python-docs-fr

Additionally, I see many .po files in the repo here: https://github.com/python/python-docs-fr which I assume is for individual pages? Everytime a new file is added there we'd have to make some changes to the configuration to read that file on Translatewiki and allow translators to translate them.

Considering the above, and the fact that our UI is not very well suited for translation of long form text, I don't think that translatewiki is a good fit.

To give you an example of how things work, see the following project: https://github.com/WPCleaner/wpcleaner/tree/master/WikipediaCleaner/src/org/wikipediacleaner/translation

Here we read the WikiCleaner.pot file and then identify what strings have to be translated, and allow translators to translate the strings to different languages. You can see the corresponding ".po" files. This is then submitted out to the GitHub repo via a PR: https://github.com/WPCleaner/wpcleaner/pull/61 which the maintainer merges.

Regards,

Abijeet Patro (talk)10:49, 31 March 2021
 

Is translatewiki still updating every Monday and Thursday?

I finished a translation of FreeCol into Interlingue (aka Occidental) last week and have been eager to see it go live but I haven't seen translatewiki drop by GitHub to update here:

https://github.com/FreeCol/freecol

It looks like it last made an update 18 days ago.

Here's where FreeCol is for reference:

https://translatewiki.net/wiki/Translating:FreeCol

Mithridates (talk)06:37, 30 March 2021

Hi Mithridates,

For FreeCol, translewiki pushes the translations out to https://sourceforge.net/p/freecol/git/ci/master/tree/

Your translations are exported out to: https://sourceforge.net/p/freecol/git/ci/master/tree/data/strings/FreeColMessages_ie.properties

I think the GitHub repository is a mirror that is updated once in a while.

Regards,

Abijeet Patro (talk)11:09, 30 March 2021

Ah! So it's a mirror. Thank you very much.

Mithridates (talk)15:31, 30 March 2021
 
 
First page
First page
Previous page
Previous page
Last page
Last page