View source for Support

From translatewiki.net
Jump to navigation Jump to search

Note Problems? Questions? Suggestions? Write your message below. – See also the FAQ or try to catch us in IRC.

Your request has been forgotten? It's suggested to use {{Support}} in thread summaries, see also documentation.


Contents

Thread titleRepliesLast modified
Special:SupportedLanguages no longer works012:33, 5 December 2019
MediaWiki:Bs-readconfirmation-api-error-cant-confirm/en014:12, 4 December 2019
MediaWiki:Discordnotifications-article-deleted/en315:34, 3 December 2019
Wikimedia:Wikipedia-library-342e87-This program is administered b outdated?021:12, 1 December 2019
About Ajapaik:web-bc7819-Unknown/fi017:41, 27 November 2019
Username change105:44, 15 November 2019
Cannot save translations due to 'interface-admin' permission910:53, 13 November 2019
French spaces2907:44, 13 November 2019
S'gaw Karen portal doesn't have English name 100:26, 13 November 2019
Reporting typo in source100:24, 13 November 2019
Is (Icelandic) vandalism321:00, 11 November 2019
Username change request100:11, 11 November 2019
Request for query in database215:19, 10 November 2019
FuzzyBot imports already fuzzied.217:49, 5 November 2019
FreeCol215:58, 5 November 2019
MediaWiki:Logentry-bs-privacy-anonymization/en please verify the original text of the message317:30, 2 November 2019
< in messages420:43, 1 November 2019
"WebAuthn" extension511:04, 1 November 2019
MediaWiki:Globalrenamequeue-email-body-approved-with-note214:36, 31 October 2019
Special:ContributionScores does not dsiplay accurate figures913:49, 29 October 2019
First page
First page
Previous page
Previous page
Last page
Last page

The special page giving the list of Supported languages (linked from the tools in the sidebar) no longer works. As well all subpages listing the users from one of the languages listed. Was it uninstalled unexpectedly, or disabled because a recent upgrade of Mediawiki caused was incompatible and the extension for this special page no longer works or crashes ?

Verdy p (talk)12:32, 5 December 2019

typo in English source "confirmtaion" > "confirmation"

Verdy p (talk)14:12, 4 December 2019

The text of this message is "❌ $1 has deleted article $3 Reason: $3" but I suppose the correct text of this message should be: "❌ $1 has deleted article $2 Reason: $3"

Robby (talk)07:37, 30 November 2019

There should also be a period (.) after "$2" and before "Reason:", like in other similar messages. This is not the same sentence. (and may be $2 should be between quotation marks, as a deleted page normally would have no visible link to delimit the displayed title). So the English message should be ❌ $1 has deleted article "$2". Reason: $3.

Verdy p (talk)18:02, 30 November 2019
 

The issue has been solved now.

Jon Harald Søby (talk)14:04, 3 December 2019

Except the missing quotation marks (delimiting the title) and the full stop before "Reason:"

Verdy p (talk)15:34, 3 December 2019
 
 

Wikimedia:Wikipedia-library-342e87-This program is administered b outdated?

Hi!

I think Wikimedia:Wikipedia-library-342e87-This program is administered b/en should have been marked as outdated while importing, because the imported French translation did not really match with English original. Could you check that?

Pols12 (talk)21:12, 1 December 2019

The source says Tundmatu. I think it should say Unknown.

Nike (talk)17:41, 27 November 2019

Username change

Hi, can I request a username change to (شريف), please? Thank you.

محمد شريف (talk)15:39, 6 October 2018

Done Done

\m/etalhead 19:17, 7 October 2018
 

Cannot save translations due to 'interface-admin' permission

I am localising the group 'Wiki Editor' into Konkani:

https://translatewiki.net/w/i.php?title=Special:Translate&group=ext-wikieditor&language=gom-latn&filter=&action=translate

It seems that 71 out of the 186 messages require the editinterface right. How can I enter these translations? Could I request for the editinterface right, at least on a temporary basis, or is there someplace where I save the translations to be entered by someone else?

The Discoverer (talk)10:52, 11 October 2019

You already have the 'editinterface' right which is assigned to the 'translator' usergroup. However, I notice that some messages are recognized by the software as having JavaScript content model and require the 'editsitejs' right, which is assigned to the 'interface-admin' usergroup. Maybe it's your situation?

Vlad5250 (talk)14:48, 12 October 2019

For example, if I try to save this message:

https://translatewiki.net/w/i.php?title=MediaWiki:Wikieditor-toolbar-help-heading-description/gom-latn&action=edit

I receive the following error message: "Saving the translation failed: You do not have permission to edit this JavaScript page because it may affect all visitors. Permissions for editing of sitewide CSS/JS/JSON files were recently separated from the "editinterface" right. If you do not understand why you are getting this error, see mw:MediaWiki_1.32/interface-admin."

The Discoverer (talk)18:57, 12 October 2019

Please help.

The Discoverer (talk)04:00, 4 November 2019

You need the 'interface-admin' permissions to do that.

Vlad5250 (talk)06:11, 4 November 2019

There are around 70 messages in the 'Wiki Editor' group that require this permission. How can I enter these translations? Could I request for the 'interface-admin' permission, at least on a temporary basis, or is there some place where I save the translations to be entered by someone else?

The Discoverer (talk)09:22, 4 November 2019
 
 
 
 
 

French spaces

Edited by author.
Last edit: 20:00, 11 November 2019

Hi there,

Verdy p insists to put narrow non-break spaces (U+202F) everywhere instead of normal non-breaking spaces (U+00A0) before or after punctuation symbols in French translations. Narrow non-break spaces are not compatible with all browsers, notably Safari on macOS and iOS, which is a big part of the readership on Wikipedia and elsewhere. Instead of a space, there's no space at all.

In French typography, both are correct but the normal non-breaking spaces have the advantage of being compatible everywhere and being coherent with the choice made by MediaWiki, the French Wikipedia community and the other French-speaking projects.

He also use translations that are rarely used [1].

Can we do something?

Thanks.

Thibaut (talk)17:36, 11 November 2019

Hello, I support the fact that we need to be accessible for all and Verdy_p doesn't help with that. He don’t want to understand this point.

Lyokoï (talk)17:49, 11 November 2019
 
Edited by author.
Last edit: 18:56, 11 November 2019

Not compatible ??? They are standard since so many years. I've never seen any browser not supporting it since extremely long. May be your iPhone is very old. But your claim that iOS is a very large is false. It is a small minority (and even much smaller if you consider very old versions of iPhones with outdated fonts).

NBSP are incorrect in standard French, they were used 20 years ago but NNBSP was adopted after many requests from French publishers. They are even required for Mongolian (OK this is a minor language) and other Asian scripts where they are even DISTINCT from NBSP.

May be they are not used in wikitext of articles, because this is simpler, but they are used since very long in translate wiki for the UI.

Your claim of "incomplatiblity" is not justified by any proof. NNBSP is in Unicode since version 3.0. They are also standard in French translations for CLDR.

The source code of ICU for iOS perfectly handles NNBSP:

Lot of iOS/MacOS programmers are told about what to do: NNBSP support *is* highly recommanded and its support is integrated in many libraries

ADE 2.0+ (more precisely RMDSK 9.2 and beyond) display correctly the nnbsp whatever may be the font. This applies to a lot of ebook-readers like Kobo. InDesign does the same.

No need of any font mapping for whitespaces. The Unicode properties are honored by compliant renderers (indepenantly of the supprot for the Mongolian script which is still problematic and still in discussion in 2019, these talks do not apply to the encoding of any other script)

Unicode states already (and agrees) that:

  • NNBSP is non-breaking
  • it has a fixed width in all contexts
  • it is not expandable during justification (NBSP is expanded and is NOT usable as a group separator or punctuation separator).
  • it MUST be narrower than a regular space or digit (FIGURE SPACE is like NNBSP but not suitable as a group separator, only as a digit replacement in tabular data when no zero should be visible). For monospaced environments, rendering it as a full space (like the FIGURE SPACE) is NOT acceptable.
  • it should behave like the FULL STOP or COMMA in the middle of numbers or in sequences of punctuation signs.
  • it is a significant character (not a format control like the Mongolian MVS, or ZWNBSP, or ZWSP, or WORD SEPARATOR).
  • it is not necessarily ignorable in all locales for collations (e.g. when it is used to differentiate numeric codes)

Unicode really instructs auhtors to NEVER use NBPS for group separators in numbers, but use NNBSP instead. Since the origin, NNBPS was introduced to be script-agnostic (the claims made by some that NNBSP was only for Mongolian was wrong, this created a temporary bug in Apple's code, reclassifgying it incorrectly as neing for Mongolian, Apple fixed that very fast as it was their error). Initially NNBSP was flawless, even in iOS ! all other apps (including Discord on iOS) have fixed that (or they provide a workaround in their app-builtin renderer for the few remaining iOS phone versions affected by this bug committed incorrectly by a Apple programmer). These smae vertsion of iOS (only with their builtin bogous Safari browser and no other browser installed) are not even accessible (so the claim of "'accessibility" being broken only by NNBSP is false; these versions of iOS are not accessible at all for MANY other reasons). All this does not concern MacOSX and all newer products that have fixed this bug (and now support Mongolian much better).

The affected software versions are NO longer maintained by Apple, and this was a propriary bug on a very small set of specific implementations that is out of market since long. and Apple has made many tricks in iOS so that even these models are no logner usable with all the needed security and accessiblity features that are needed today. These old versions were even incompatible with Mongolian (and never supported that script correctly, allowing only very bogous and ugly rendering of Mongolain only in its horizontal form, but incorrectly rotating some glyphs and not rendering the basic required conjuncts correctly).

You also made a false claim that Discord is only for iPhones. I use Discord (on Windows, sometimes Linux, also on Android) but I've never used any iPhone. All modern browsers support ALL spaces (without even needing any font mapping, as they can be synthetized, given they have no glyph, and just suggested metrics that can be computed, and standard breaking properties). NO browser must display any "tofu" for characters that have a Whitespace property. This is effective since long.Unicode provides the fallback mechanism and explicitly says that the default fallback must be either nothing/zero-width (for languages like English or Mongolian, or in every monospaced rendering, including Chinese, Japanese, Korean) or NBSP (for French for example) if the browser cannot synthetize the metrics for proportional rendering.

Even in XP, there's no problem. May be there are very old version of IE, but they are so old that they cannot even support the minimum Javascript that is needed for Mediawiki or even Discord itself! Their users are instructed to install and use another compliant modern and supported browser (like Firefox, Chrome, Chromium, Opera...) of they don't comply to the standard and don't even have the minimum Unicode 4.0 support (NNBSP was pubnlied long before in Unicode 3.0, I don't know any browser that just supports Unicode 3.0; not even in plain-text console browsers where NNBSP should be invisible with monospaced fonts, and this is not a bug, while NBSP is very ugly in such context where NO extra spacing is needed with punctuations or even as group separators in numbers, where these group separators for accessibility do not math the fact that monospaced text is already not designed to be accessible or even compatible with all scripts).

Note that even if NNBSP was initially introduced for Mongolian, it was later replaced in the Mongolian script by MVS (Mongolian vowel suffix separator). It was not deprecated at all for other languages (FVS1, MVS, ZWJ are now recommended for Mongolian, which is a vertically written script, whereas NNBSP, ZWNJ, FVS3, FVS2 are deprecated only in Mongolian; the NNBSP remains the non-breaking equivalent of THINSP for all other scripts)

Verdy p (talk)18:01, 11 November 2019

Hi.

TLDR;

Thin space is not visible on my ipad (iOS, Safari), so I reverted your edit. Thin spaces are cool (we often use them in press and printing), but as long they don't work on all common OS/web browsers, don't use them.

Regards.

Jules78120 (talk)18:33, 11 November 2019
 
Edited by author.
Last edit: 19:37, 11 November 2019

tl;dr as well.

"May be your iPhone is very old."
Nope it's not.

"Your claim of "incomplatiblity" is not justified by any proof."
Here's a screenshot from Safari and another screenshots from Firefox, Chrome and Opera. All browsers on iOS must use the same web rendering engine as Safari anyway to be accepted in the App Store.

"You also made a false claim that Discord is only for iPhones."
I didn't say that, I said that Discord is often used on mobile and translations should be fully compatible on all current mobile operating systems, including iOS (all translations on this website should be). Btw I'm using Discord on my Windows PC right now.

FYI, I just tested on Safari 12.1 on macOS 10.14.4 (Mojave) and the thin space is invisible as well (screenshot).

Edit: Like Jules78120 said above, thin spaces are good for books and publishing but a bit overkill for interface messages and strings of text sent by a bot.

Thibaut (talk)18:36, 11 November 2019

There is 2 problems here:

  • the typography, thin space is in theory the good solution but it doesn't work
  • the attitude of Verdy_p, unable of efficient and sane discussion

The first is technical, we can look at the facts and act accordingly.

For the second, I have no idea and I'm sorry but I prefer to let someone else do something about it.

VIGNERON (talk)19:05, 11 November 2019
 

Not compatible ? Only uninformed users. See:

https://www.mobileread.com/forums/showthread.php?s=d2dc1cdf14e21e2f251a838f4e7dcfc4&t=189487

Many places in Apple forums and documentation tell that NNBSP *is* supported and even strongly recommended (and no need to embed any font in your ePUB; as well there are other ePUB readers, and were's not even translating here any interfzace of old proprietary ePUB reader for Apple OSes). Apple has fixed its readers and published the details for authors.

So this is a problem of 'lazy' users refusing to read the recommendations that are largely adopted everywhere else (and remember that users of these old Apple devices are a very small community, ready to pay to lot to Apple, but refusing to upgrade their device, OSes or use a better software than the builtin default?) Accessibility is not a concern. All standards agree that NNBSP is and must be supported and the initial bug of Apple has been acknowledged by Apple, and tyhe work around has been made in all serious apps (including in Discord for iOS).

And if you feel offended by the term "lazy", this is a fact: I give many justifications and there are tons of links on the web and support not just from me. But if you don't want to read them, you don't need to talk here and just say "TLDR" (which is NOT a valid argument).

Verdy p (talk)19:08, 11 November 2019

Ad hominem attacks are not arguments either.

"So this is a problem of [...] users refusing to read the recommendations that are largely adopted everywhere else"
That's the pot calling the kettle black, you refused to acknowledge that the Imprimerie nationale and the Office québécois de la langue française, two authorities when it comes to French typography, don't recommend thin spaces between French quotes.

Thibaut (talk)19:35, 11 November 2019

And here this is about ":" and about a user not seeing the space which is present and visible in its own screenshot. And this is for the UI on specific smartphones or small tablets. No user will have to input this, as it is only displayed and convenient for them. And you have a very strange interpretation of "ad hominem". I gave many sources, and all standard bodies and even Apple have approved it, reaffirming that NNBSP was for this purpose (decommitting it only for the Mongolian script for which it was initially unified in the first encoding in Unicode 3.0). Unicode, CLDR, Apple, Microsoft all recognize that this is strongly supported (and was demanded by many publishers, including in France; do you remember that I have worked for many years for ALL publishers in France (for national and regional newspapers, magazines, books, guides, diaries... as well as professional/specialized press, and public papers) and also in Belgium, Luxembourg, Switerland, Italy, Spain, Canada, North Africa, Lebanon, and the Middle East: they all demanded that support in the composition softwares we were selling them. At that time, HTML was not used (it was insufficient and the NNBSP was not even existing in Unicode, but the character already existed in SGML and in their databases of encoded texts (they were represented using defined character entities). That "fine insécable" was (and has remained) required as the group separators in numbers and along with all punctuations needing extra spacing attached to them. Using NBSP was unacceptable, and in Unicode the NBSP is expansible like regular spaces, making it unsuitable (and totally incompatible even as group separators and in all financial applications as it would become confusable with figure spaces (which are also unexpansible) The two authorities you speak about made old recommandations for HTML but this was before Unicode 3.0. They were both asking for a proper support of NNBSP since years to the W3C and to ISO and Unicode. This was affirmed by them in the ISO standards and working groups for SGML (which was then their reference framework; their adoption of HTML came much later and now Imprimerie Nationale also uses HTML publications with NNBSP: the old recommendation for old versions of HTML3/4 and based on legacy 8-bit charsets is no longer applicable).

Verdy p (talk)12:51, 12 November 2019
 
 

Your screenshot is using a font whose glyph for ":" is already enlarged, and Unicode also sayss that in such case it is perfectly acceptable for NNBSP to become invisible.

This is a same rationale with the ideographic rendering with fullwidth punctuation: they dont need extra spacing at all.

NNBSP is in the Times font recommanded for ePUB (and supported as one of the 7 default fonts for the Apple's iBok reader not needing any font embedding). It is used by default in serious publications.

If you use the default font for the web which uses enlarged characters for accessibility (or you tune Windows web browsers with Verdana instead of the default Arial or Segoe UI), NNBSP can legally be mapped or tuned by the browser to become invisible (this is legit, it remains fixed-width, non expandable by justification, and non-breaking as expected). NBSP breaks the text and is too large (it can be a valid fallback only for FIGURE SPACE, as long as it is not expanded in justification like regular SPACE).

NBSP does not have the needed properties. All standards agree : CLDR, IBM, Apple, Unicode, Mozilla, Microsoft, LibreOffice, Monotype, French typographic sources and publishers (including commercial ones, like Hachette, or public ones like the JORF), and even US publishers for English: they all use NNBSP for French punctuations and group separators.

NBSP was a temprary workaround used at the early stage of Unicode before version 3.0. When Unicode 3.0 was published, it was correctly supported as well by Apple, until they started creatging havoc and proposed a way to fix it. Renbdering NNBP as an invisible space is valid with the default proportional "sans-serif" fonts of MacOS/iOS whose glyph metrics already embed larger gaps between glyphs. Helvetica (licenced by Apple from Adobe) embeds the NNBSP character, but that old font is not recommended at all for reading the web on a screen (even with HiDPI screens) as it is not accessible and was only tuned for monochromatic laser printing at 150-300 dpi. Helvetica is deprecated but remains a default for old MacOS devices (not MacOSX that have better fonts with more accessible metrics).

Verdy p (talk)19:27, 11 November 2019
Edited by author.
Last edit: 19:55, 11 November 2019

Maybe your technical explanations are true (but not sure: my iPad, "given" by my employer, is not old and is up-to-date…), but what I can say is that on my iOS device, on Safari, the thin space is not displayed. Please stop arguing about the theory and take into consideration the reality

Regards.

Jules78120 (talk)19:43, 11 November 2019

And please stop to impose your thin space, as there is no consensus for it and while thin spaces are not displayed on iOS devices.

Jules78120 (talk)19:46, 11 November 2019
 

Why do you want to force a visible space here ? When your device uses a font with builtin enlarged punctuations ? With such a font with ugly punctuations like ":", NNBSP being rendered invisible is NOT a problem. This is legit. But NBSP is definitely bad (even worse with your font, it would be definitely too large). You msut know that NNBSP is used in so many places. Apple has made statements about how to cope with that. If you use the default builting sans-serif fonts even in browsers, haing it invisible is correct; if you render the page with a serif font, the default builtin font "Times" correctly renders that NNBSP. In both cases, it is supported.

If you use other fonts than these defaults, you will see the difference if you insist,, but such use is only for page design or when writing text, and even in the Wikitext editor you can see it with the monospaced font. But for the UI rendering it's still best to have it rendered as zero-width near punctuations (not at all an accessibility problem for this font). In fact it better fits the limited screen size on lowend iPhones.

And on the web, nothing forbids you to change the fonts (there are preferences for that in Apple's web browser). Did you read the links above ? Apps and other browsers can still work around this when they need, even if fonts don't map this character and EVEN if they are forced by Apple to use the Safari's internal rendering engine.

You don't care, but you're part of a very small minority and the large majority want to use the standards and official recommendations (that don't even break your device and makes the content inacessible to you if you don't want to change the device settings).

Verdy p (talk)19:55, 11 November 2019
 
 
 
 

About the thing of uncommon translations, it is completely besides the point of this thread but you people should avoid just indiscriminately adopting English terms when you could use plainer terms, and in this case, “en source ouverte” is a direct, easy-to-understand equivalent of “open source”, understandable for people beyond geeks. Other Romance languages translate the term as well: de código abierto (es), de código aberto (pt), de codi obert (ca), de códigu abiertu (ast), cu sursă deschisă (ro)… Anglicisms can be necessary and I don’t censor them, but in this case it is gratuitous and avoidable.

Fitoschido (talk)23:50, 12 November 2019

C'est aussi mon point de vue. Je ne vois pas l'intérêt de l'anglicisme ici, nombre de geeks se foutent pas mal de leur langue tant qu'il parlent leur jargon technique et ne cherchent justement pas à impliquer les autres et se fichent pas mal de rendre leurs projets accessibles et compréhensibles par plus de monde.

Rien n'empêche de toute façon ensuite aux techniciens bilingues et les mieux formés d'utiliser le terme anglophone quand ils vont sur des espaces anglophones, mais puisqu'ils sont mieux formés je ne voit pas ce qu'il leur en coûte d'utiliser une terminologie française correcte dans une traduction française qui justement ne leur est pas destinée directement, mais qu'ils comprennent très bien.

Il n'y a rien de plus rebutant pour un novice de se confronter à autant d'anglicismes non nécessaires dans les projets collaboratifs supposés justement "ouverts", mais qui se replient justement à des petites communautés installées de techniciens qui se croient irremplaçables et indispensables et les seuls à "savoir" (alors qu'ils méprisent autant le savoir de langue humaine, au seul profit du jargon informatique où ils sont les "dieux"). Nos projets devraient être ouverts aux novices, et c'est encore plus important pour ici un terme qui veut dire ouvert à tout le monde, et dans un contexte aussi promoteur de l'éducation que le veut clairement Wikimedia. "Tout le monde" ne veut surtout pas dire "Tout le monde anglophone" (sachant aussi que le jargon informatique déforme et abuse aussi beaucoup la langue anglaise avec trop de raccourcis, et encore plus d'expressions ambiguës qui ensuite viennent "plomber" même le code écrit).

Faire comprendre un terme technique permet aussi d'éviter les mauvaises interprétations et les mauvais usages, même si ensuite l'association vers un terme anglophone correspondant est vite apprise. Tout est une question de respect et d'ouverture aux autres.

Verdy p (talk)01:18, 13 November 2019
 

If we really want to translate this common anglicism, the correct French translation would be "code source ouvert", not "source ouverte", which is a bad calque from English.

Thibaut (talk)06:15, 13 November 2019
 

In general, MediaWiki tries to follow Unicode. We could debate forever on what to do with devices which have poor support for i18n. This is a matter of style, not semantics, so we ought to be consistent (ideally) but at the same there is no urgency justifying a mass edit war.

I use DjVu Serif and an edit like special:diff/9131394 adds a space for me before the colon, where previously there was none. It's clear that the translations did not follow a consistent rule.

I urge the French translators to have a discussion on portal talk:fr (in French is better), involving all those who used or did not use the various kinds of spaces in the past. It's important to find a consensus on 1) what space would be preferrable in an ideal world, 2) what space is recommended right now (this should be written on portal:fr so future translators can learn about it), 3) whether it's ok to perform mass changes to impose the recommended style.

I suspect the solution will come from software, just like we have a special exception in the MediaWiki parser to deal with French spaces. After you have a consensus on what an ideal world would look like, please post a feature request in MediaWiki-Internationalisation, so the devs can see whether spaces can be added/standardised on the display side (some even use CSS for this purpose, I believe), possibly based on the device as well.

Nemo (talk)07:44, 13 November 2019
 

S'gaw Karen portal doesn't have English name

In Portal:ksw, the English name for the S'gaw Karen language is not shown, it only have the native name. Please add the English name like any other language portal.

Jaeminlovetaejoon (talk)04:02, 10 November 2019

Done (not in the portal page itself but in a template, which is used when any language has missing or deficient support in Mediawiki itself and lacks important translations or transcriptions in important scripts). Verdy p (talk) 00:44, 11 November 2019 (UTC)

Verdy p (talk)00:44, 11 November 2019
 

Reporting typo in source

Typo Wikimedia:Wikipedia-ios-diff-thanks-sent/en: "set" should be replaced with "sent".

Papuass (talk)13:22, 11 November 2019

I submitted a pull request to fix this, so I expect they will add it to fix the problem swiftly.

Jon Harald Søby (talk)00:21, 13 November 2019
 

Is (Icelandic) vandalism

I spotted an edit which cannot in any sense of the word be considered an translation. This edit is [1], which adds an Icelandic male name to an field named "Add language". This is grossly inappropriate and I am requesting that his "offline translator" rights are removed due to this. You really can't expect other translators to clean up an mess like this one.

Snævar (talk)11:54, 24 October 2019

Is this a regular occurence or just a one-off? In assuming good faith, I would believe it's just an honest mistake. I could see myself doing the same thing – thinking I'm copypasting in one thing, then not noticing I copied the wrong thing. It can happen.

Jon Harald Søby (talk)15:20, 24 October 2019

It is the worst edit of several bad ones (of those I have found, anyway). It has also happened that I have fixed his translations and then he just re-adds the old translation, that either can´t be considered an translation or contains a word that does not exist in the language.

It would be better if the user had normal translator rights only. An translator can in theory use their offline translator rights so that they use an old translating file and update from that. The problem with that is that that user would end up ignoring other peoples edits while doing so. I suspect that he has uploaded the same offline translator file more than once, and ignored any improvements by others in the proccess. So, I belive he would be an better translator with normal Translator rights only, as it would show him the most recent improvements every time.

It does not help matters either that there is an lack of vandalism tools here. There is no AbuseFilter, TitleBlacklist and so on.

Snævar (talk)13:23, 8 November 2019

@Snævar: OK, fair enough. But have you tried talking to him to tell about the problem? I can't see anything in the user talk page, but maybe you have some other communication channels. In any case I'm hesitant to call it vandalism, it seems more a case of not being careful enough. If you want I could post something on his talk page, but it might be better if you do it since you know the specific issues much better than I do, obviously.

Jon Harald Søby (talk)21:00, 11 November 2019
 
 
 

Username change request

Not sure where to submit a username change request. So I request it here.

I want to change my username as "A-lú-mih". Thanks.

Luuva (talk)05:56, 9 November 2019

Done Done :-)

Jon Harald Søby (talk)00:11, 11 November 2019
 

Request for query in database

Hi, can you provide me list of message groups which have less than 10 messages?

Zoranzoki21 (talk)02:36, 8 November 2019

just use the Translation tool (from the sidebar).

  • Select your language.
  • Uncheck the box restricting the list to hide fully translated groups.
  • Press the button to get the list of message groups
  • Then click on the "Expand all" link displayed
  • Click on the column header to sort the expanded list by messages count.
Verdy p (talk)02:57, 8 November 2019

Oh, thank you very much! I forgot about this, but I asked because when I usually do this from step four the page slows down and becomes unresponsive. But by some miracle it works this time. I close this thread, thanks again!

Zoranzoki21 (talk)15:18, 10 November 2019
 
 

FuzzyBot imports already fuzzied.

For the translations created by FuzzyBot that are created already fuzzied, the translation interface should be submitting them for our review, because they're fuzzied, but does not.

For example, on 9 May 2019, FuzzyBot inserted the following two translations, with summary "Importing a new version from external source":

Let's look at the first link, for example:

FuzzyBot1.png

If you start editing the message directly from this page, it is definitely fuzzied:

FuzzyBot2.png

But the edit interface does not show it in the list of "Outdated" strings. It is none of the six presented here:

FuzzyBot3.png

The message appears in the list of "All" strings, as translated and not flagged as requiring any action whatsoever:

FuzzyBot4.png

Worse still, if you open the message itself here through the translation interface, the software does not even show you that it is fuzzied. The whole !!FUZZY!! thing is totally hidden:

FuzzyBot5.png

So, just to confirm again, if you go to edit the message directly from the edit interface, as follows (greyed out menu item):

FuzzyBot6.png

you can confirm that the message is effectively fuzzied:

FuzzyBot7.png

So, it has been there since 9 May needing review, but not to my knowledge.

Hamilton Abreu (talk)19:24, 1 November 2019

Thanks for the report. I'll file task and see if I can mitigate this.

Nike (talk)14:37, 5 November 2019

I have run script that fixes this for existing imports. https://phabricator.wikimedia.org/T237412 tracks how to prevent future cases of this. https://translatewiki.net/w/i.php?title=Special:Translate&group=wikipedia-library&language=pt&filter=fuzzy&action=translate contains a lot of fuzzy messages now.

Message group stats was not updated by the script, but they will hopefully "repair" itself over time.

Nike (talk)17:49, 5 November 2019
 
 

You do not have permission to edit this page, for the following reason:

The action you have requested is limited to users in the group: Users.


You can view and copy the source of this page.

 

Return to Thread:Support/FreeCol.

It's not stopped, they just haven't been able to put out a release yet. We'll consider this in https://phabricator.wikimedia.org/T228072

Nike (talk)14:30, 5 November 2019

Now I see why they don't update like that. Thank you for this information. :)

BaRaN6161 TURK (talk)15:58, 5 November 2019
 
 

MediaWiki:Logentry-bs-privacy-anonymization/en please verify the original text of the message

I suppose the text of the message MediaWiki:Logentry-bs-privacy-anonymization/en should not be '$4 has anonymized the account account. New username: $5' but '$4 has anonymized the account $2. New username: $5

Robby (talk)23:01, 1 November 2019

I agree that the the double word "account account" was a probable error (possible incorrect copy-pasting when one of them would have been a placeholder, however the placeholder $2 suggested in the "/qqq" doc may not work here. This must be checked in the source code and may be the second "account" was there because there was still no value to indicate there (the source code may contain some "FIXME" comment tag, not shown when the message was exported from source code and imported for translations in TWN.

For now, I could not even place any occurence of {{GENDER:$2}} in the translated text, because "$2" is not present in the source English text, and inserting it would make the translated message fuzzy and then not exported from TWN.

All I could do was to translate as if the English source was "their account" (impersonal/neutral form) and not "the account account", or "his/her account" or "the account $2".

Verdy p (talk)23:14, 1 November 2019

This message was changed yesterday with the comment "Change message to be gender-neutral \n This is done because the account that gender should be determined on, is already deleted by the point this message is created". The explanation makes sense, but the resulting message (with the doble "account") should obviously be improved.

Jon Harald Søby (talk)13:45, 2 November 2019

So why not simply "their account" ? (A "qqq" documentation may explain that "their" is the impersonal gender-neutral singular in English. I initially thought that "the account account" was a typo, an incorrect replacement here which does not make sense at all and causes more difficulties to translators or even native English readers, trying to guess what it means: there's only a single account, even if now it is deleted (actually anonymized without personal data like gender). I wonder if this can apply to bot accounts: do we have bots anonymized without also anonymizing the associated owner's account ?

Can we know if an anonymized acount was used by a bot and not a normal person, and does it keep a traceable link to the now anonimized personal account ? Is is safe or even possible to anonimize an account that has a bot associated (but not renamed)? or the inverse situation where a bot gets anonymized without anonimizing the account owner (accoding to policies this cannot be accepted is the bot is still active and authorized: a new bot account should be requested and associated in that case, and the old bot account that was anonimized should then be blocked from connection to all APIs, but not be masked at all given their past impact; it remains important to know that some past edits that were anonimized were automated, and allow independat reviews or reports to analyze their past actions in history, including info possibly documenting the automation rules they used: all bots have made unexpected errors but they are hard to find in the mass and such detection can take a lot of time even after a bot is blocked or no longer active at all) ?

Verdy p (talk)17:30, 2 November 2019
 
 
 

< in messages

I’m in conflict with Verdy_p about these messages:

Verdy_p wants to turn < into &lt;. However, entities are escaped in these messages where they are included, so the messages are displayed as they are (with entity codes). You can see that on Special:PageMigration (you need to be a translation admin), trying to type anything in the field then submitting.

Pols12 (talk)18:11, 30 October 2019

You give a proof with a specific page used only by admins. But there's no double encoding of ampersands in Mediawiki. Everywhere else the "<" have to be escaped to avoid incorrect matches as candidate tags. valid numeric entities and at leastr the few basic standard characters (which are not "named entities" in HTML, but part of its required syntax) are implicitly recognized (they do not require any DTD, their supprot is mandatory in all HTML and XMS parsers, and in MediaWiki itself): "lt", "gt" for tags, and quotation marks and required for attributes and ampersands for URLs; the support is extended to numeric entities since HTML4 and in all versions of XML and mandatory in HTML5. It is mandatory since ever in all versions of MediaWiki (initially however it had limited support for Unicode and allowed numeric entities mapped to 8-bit only codepoints before UTF-8 became mandatory, which occured when HTML was fixed to require Unicode-only mapping of numeric entities, forbidding mappings to legacy codepages, even if the pages themselves would still be encoded with legacy charsets, this no longer applied to numeric entities). You're living in the early non-standard age of HTML of the end of the 1980's when MediaWiki did not exist, Translatewiki.net did not exist and HTML was full of ioncompatible proprietary versions derived inconsistantly from the initial CERN invention.

Verdy p (talk)18:54, 30 October 2019

Verdy_p, in my diff comment, I had given you a proof YOU can check because you ARE a translation admin on meta wiki!

Pols12 (talk)10:16, 31 October 2019

No, your sample page does not work for translation admins. It is only for sysadmins.

Verdy p (talk)20:43, 1 November 2019
 
 

The general guideline is to use what the source uses and not worry about escaping things (in fact, if you would need to worry about escaping, that would be a security issue). I see no reason to deviate from this guideline here.

Nike (talk)10:29, 1 November 2019
 

"WebAuthn" extension

Hello! I don't know any other place to post suggestion like this, but maybe you should consider installing WebAuthn extension as a complement for OATHAuth (2FA provider).

Thanks,

Rail (my talk | contribs)20:50, 28 October 2019

Interesting. Has it gone through a security review?

Nike (talk)17:48, 30 October 2019

I'm not really sure but I have found this ticket on Phabricator: https://phabricator.wikimedia.org/T227244

I don't see any other security-related ticket, tho. However, as far as I know, this extension will be used on WMF wikis do you can assume it's secure enough.

Also thanks for your reply,

Rail (my talk | contribs)19:52, 30 October 2019

I'd say that technically the extension is ready, but the user experience is in alpha stage, so the translation may be also alpha as long as it has not been tested; there will likely be more to translate and explain how this should work and what ot do in case of problems of configuration and why this new Auth method would be preferable or not to another (the Phabricator task explicitly questions about how to work with multiple libraries trying to do the same thing, how they can be unified using a replacable hook allowing to evaluate also the implementations in terms of effective security, performance, cost of maintenance, debugging in case of problems. Also the testbed is still not in place, and they wonder how they'll recruit testers with usable inputs (or if automated monotoring can generate better results). In terms of pure UX, the testbed will receive some comments, several proposals will be made, as well as A/B tests. How many testers will be needed will also condition how many languages will be needed for these tests (they probably don't want to support many languages for now, but have enough inputs for specific needs in some countries where other authentication methods (possibly using thrid party services) are not supported very well, or have no good support and fow which alternate less demanding methods may be needed, but also more training for their users.

Still in all countries, 2FA is not enough known and not generalized, many users complain about how the current methods are implemented, and they also fear about privacy risks this causes to them (notably in countries like China with very active user monitoring by authorities, or with extreme social/economical and criminal risks like Russia or Mexico, or legal risks like US, or countries where users have no other choice to conenct to Wikimedia than using foreign VPNs, or slow mobile connections, or shared Internet access, or whose emails are heavily monitored

As well there's a worldwide threat caused by malwares that attempt to steal people's identity, and 2FA will sonn be not enough, we'll need more factors in a very near future. But how we'll configure all these to work correctly together may become really complex for many people, that will finally opt to protect their privacy by delegating everything to a commercial service provider like Apple, Google, Facebook or Amazon, and tie all their existence to a permanent dependency to these big players, creating lifetime monopoles and splitting the world in distinct proprietary universes.

Verdy p (talk)22:39, 30 October 2019
 

I'll consider this. It's not on top of the TODO list so it can take a while.

Nike (talk)10:30, 1 November 2019

Awesome. Thank you.

Rail (my talk | contribs)11:04, 1 November 2019
 
 
 
 

MediaWiki:Globalrenamequeue-email-body-approved-with-note

Globalrenamequeue-email-body-approved-with-note uses $1 on both, the old and the new username. Shouldn't it use $1 for the first and $2 for the new one?

MarcoAurelio (talk)22:01, 29 October 2019

$2 is the proposed new name, it still does not exist under this name so it cannot be queried for gender. Both names refer to the same user currently named $1, who has the gender settings (these user settings will be applied later to the new name once it is applied; then $1 will no longer have its own settings, it may be deleted/hidden, or kept as a public redirect (possibly protected against deletion or modification of its user pages and talk pages). So this is the same gender of $1 which would apply to both names.

Note that the gender may be needed only in a few language for grammatical forms. If a translation does not need it, the GENDER marker must still be present but may containt empty text (in the English text, the text is the visible user name, not the gender itself, and there's no alternate gender variant of that name and no need to add any other personal gender particle which may be required in addition to the specific user names (I think these gender particles are needed only in some native African languages; in some Slavic languages, there are sometimes variations of user names depending on case on specific constructs, which are also dependant on gender).

Verdy p (talk)22:46, 29 October 2019

Thank you Verdy p for the very helpful explanation. Regards.

MarcoAurelio (talk)14:36, 31 October 2019
 
 

Special:ContributionScores does not dsiplay accurate figures

Hello,

during the last few dates I noticed that on the page Special:ContributionScores for my User for Last 7 days (Top 50) the number of contributions is marked as following:

Rank Score Pages Changes Username

49 9 9 9 Robby

while on [1] you may see that I made at least 50 edits on 31 August till 2nd September.

So there seems to be something broken on this.

Robby (talk)22:33, 1 September 2019

49 or 50 edits, this is not a huge difference, and the statistics are not counted immediately; your last few edits were probably made after the statistic batch was run (so it counted only 49). Look at the statistics after 24 hours, you should see evolve it (but the count may still be off by the edits you made in the last few hours after the batch ran). Verdy p (talk) 23:35, 1 September 2019 (UTC)

Verdy p (talk)23:35, 1 September 2019

I've the same problem since the last days of August. I'm on 27th overall ranking but my changes are stopped on 38201 (and the scores is stopped too). May be there's a bug?

Joe Taras (talk)16:56, 2 September 2019
 

You are mistakken 49 is the rank not the number of changes or pages these were 9 and there is quite some difference between 9 and over 50.

Robby (talk)21:27, 2 September 2019

OK, but your actual statistics is not 50 but over 70,000. Still my comment remains valid: the statistics are not computed all the time continuously but with batches running periodically, so it's normal that it can ignore your most recent edits over the last shortest period. As well, the results depend on the activity of the job queue (which is very active on this wiki even if there's few edits, as the longest jobs are those created for SemanticWiki, some of them running for hours may lock temporarily not just some pages but also the updates of related statistics (which will be deferred). These statistics are not intended to be actualized in real time, they are just estimates. Computing them has a huge cost on the server, so they cannot be refreshed instantly, even if this is based on a live SQL request (which is already costly and quite long to reply for this page, because it has to lookup all existing users to sort them and then extract about 50 of them in each "top list"; the statistics however are quite accurate for least frequent users, but must frequent users are only roughly sorted, especially for the shortest period of 7 days). Note also that the computed statistics do not show the actual period of dates on which they were computed: the period may be off by more time than what you expect, and the "last 7 days" may be 7 days before the last run of statistics offline jobs which may have occured up to 7 days ago (possibly more of the database had long job lists, with some jobs taking several days to complete and deferring other pending Statistics jobs to run that, most probably, have lower priority than Semantic jobs and regular jobs built in MediaWiki).

This statistics page is not certainly the one to consult if you want to get your own personal edit statistics, that you can get using the live Mediawiki API:
"https://translatewiki.net/w/api.php?action=query&list=users&usprop=editcount&ususers=MYUSERNAME"
For example: https://translatewiki.net/w/api.php?action=query&list=users&usprop=editcount&ususers=Robby
The same for Joe Taras: https://translatewiki.net/w/api.php?action=query&list=users&usprop=editcount&ususers=Joetaras (note: you must use the actual username, like in your user page, not the displayed username in your signature, and URL-encode it if needed in the URL) This gives a total on all periods. Computing this over a period is much more complex as it requires scanning your history, so this cannot be done directly with the live API. Doing that on all existing users (just to get the Top 50 lists) is even more complicate and costly.

Verdy p (talk)21:13, 3 September 2019

Ok for me. Usually I've checked my stats and I've seen updated. Maybe there's a lot of traffic. No problem. Thank you for your reply

Joe Taras (talk)21:53, 3 September 2019

Dear, I must return on this issue. I've understood the performance is important but, if we can't see the updated information about edit count and other, please remove some functionality from Translatewiki, as follow:

The page SupportedLanguages is unuseful because if I check information about an user the information are not update, as the following image:

User activity detail.png

The page Contribution scores is unuseful because is not update, as the following image:

Contribution scores detail.png

And these widgets

Widget on edit count.png

I'll wait for your response.

Have a nice day

Joe Taras (talk)09:59, 29 October 2019
 
 
 
 
 
First page
First page
Previous page
Previous page
Last page
Last page