User talk:Verdy p

This discussion page previously used LiquidThreads. You can see and continue those discussions on the LiquidThreads archive page (all archives).

CVS > CSV

Hello, Verdy p. Could you please also fix or report (whatever is applicable) the following: "We are already familiar with CVS, Subversion and Git." (at [1])? The correct acronym would be CSV. Thank you. --Eleassar (talk) 16:15, 14 February 2023 (UTC)

@Eleassar: No, you're wrong and confused: CVS is the acronym of the "Concurrent Versions System" ; here it is definitely not CSV for "comma-separated values", which is unrelated here (I'll comment it in the doc). Verdy p (talk) 16:27, 14 February 2023 (UTC)

I've updated the doc page and reverted your edit in the English source. Verdy p (talk) 16:34, 14 February 2023 (UTC)

Ok, thank you. --Eleassar (talk) 17:11, 14 February 2023 (UTC)

I've fixed a few other messages where CSV and CVS have been incorrectly confused, and added a warning as well in their doc. Various translators are not aware of the difference.

Ideally such abbreviations or acronyms should always be documented.

Note that the acronym "CVS" is not translatable as it is the name always used for the product. Whereas the abreviation "CSV" is more fuzzy (the CSV format for tabular data files has many variants, with different separators and not necessarily the comma; there are multiple ways to escape strings, or separate records, and multiple possible encodings, not always UTF-8, but many apps still refer to them as "CSV" files) and may be translated differently (others used "TSV" for tab-separated values, but if the 3 Latin letters CSV are used in English for this case, they should really keep their order to avoid the confusion: we can have frequently CSV data files stored within CVS repositories!). Verdy p (talk) 17:18, 14 February 2023 (UTC)

Codelookup

Hi! Re. [2], what do you mean when you say it doesn't work for ISO 639-2B/T/3 codes? Jon Harald Søby (talk) 08:41, 8 March 2023 (UTC)

It gives no info at all about unsupported codes, as if they did not exist. As well this does not work with ISO 639-5; it is made from BCP47 and Wikimedia legacy codes. The code lookup tool actually was made for basic checking of translation requiremetns for creating new wikis. It is used mostly on Incubator by the Wikimedia Language Committee to check also the completion status. It is different from the previous tool (no longer working and that you tried to replace) that made a real complete lookup of ISO codes (but not BCP47 codes and not Wikiemdia legacy codes). That tool stopped working on toolforge and was disabled (and it is still disabled). There are separate code lookup tools for ISO 639 codes (for each code type), and they are already used and linked in the portal template. Verdy p (talk) 09:48, 8 March 2023 (UTC)

The ISO check in the previous version wasn't very sophisticated, all it did was to look up codes in a static list from 2012 (it was probably complete back then, but certainly isn't now). I didn't bother implementing anything for ISO 639-2 B/T codes because all those languages (except some edge cases, I know) have ISO 639-3 codes. And why should the tool work with ISO 639-5? The entire point of the tool is to check a language code's validity for a Wikimedia projects, and language groups/families are not eligible for obvious reasons. Jon Harald Søby (talk) 14:29, 8 March 2023 (UTC)

I know, but the previous links have been disabled and were performing lookups independantly of which standard defined them, and could find and locate the correct code to use. I had then already added the link to check codes used by Wikimedia in the Wikiemdia section, using the same title used in Incubator language portals). For each ISO standard, there's a check link in the appropriate maintenance agency site, so there's no need to repeat another check after each ISO code for how Wikimedia uses them. Verdy p (talk) 14:41, 8 March 2023 (UTC)

Ellipsis or not in French

Hi, my colleague user:MohitMali is a bit lost with the handling of the ellipsis in Kiwix Android. I try to help him and actually I believe we should use the ellipsis Unicode charachter everywhere. This is the idea behind my last modification. If there is any reason in French (on TW) not do so, can you please share here the rationals? Thank you in advance for your help and all the work done on Translatewiki; this is so helpful. Kelson (talk) 16:26, 19 March 2023 (UTC)

Perhaps in Android this is true, because you app mostly uses strings for the UI and the UI is not tuned to target legacy consoles.

But you should be aware that the only reason that the ellipsis was encoded in Unicode was to support legacy 8-bit charsets, where it was better to have these grouped into a single character, specifically for that use. But the "ellipis" is limited in the fixed number of dots it supports. If you look at the Unicode character database, since ever it had also a compatibility mapping to single dots, and that single dots continued to be used everywhere there was not 3 dots. The other impact of the ellipsis character is that its compaction into a single character changes significatntly its metrics (notably the leading and trailing padding, and the size of the dots to make them fit. But beside the "modern" use with monospaced fonts for terminals (or old printers and teletypes) during a few decenials, there's a much longer typoigraphic tradition for those punctuations to be treated as separate dots. Proportional fonts have then restored that tradition (and are also now used on modern OSes, including Android for its UI).

So there's no reason at all to use what was a legacy character, that it in fact not needed at all except for specific legacy applications (that Android has never targetted for its UI). The other reason is motivated by collation and better support of text indexing engines: it's not easy to type and search ellipsis, and expect you'll find every occurences you need (all cases of ellipsis in natural texts, independantly of the target platform or usage).

Another reason is unification with translation memories: if you make an exception for Kiwix, then you have different ways to represent/encode the same meaning. Note that the legacy ellipisis character is NOT supported in all environments. Instead French (but not onty) really treats it always as being only a semantic grouping of three dots (full stops), and ensures that such occurenes of three dots are also always considered being an ellipsis: there's NO distinctive use semantically (that not the case of accents or capitals which can be constrasted and whose distinction MUST be preserved and cannot be freely mixed).

Allownig such mixes when there's no distinction needed just complicate things (and no search engine or indexing treat it differently, but this complicates their implementation, and some basic implementations will incorrectly treat the encoded ellipis as distinct from the sequence of three dots: this is an unnecessary complication). And if some fonts for technical use only (for the UI to be read by humans) need to make a distinction for that use in its rendering (to mimic the behavior needed on legacy consoles, typewriters or teletypes, where the use of monospaced fonts had a cost in terms of paper use that could be locally saved using some "contraction", with a very modest gain), it is not needed at all with proportional fonts and also not needed in terms of data length for the encoding (notably with the UTF-8 encoding: you gain nothing, and instead, on transmission, it even compresses less on networks, e.g. within packaged apps). The Android UI clearly never needs it (of Kiwix should also not need it at all even in Android, or iOS if you target it, or more generally web pages rendered in a wiki). It is also a pain for all text editors (that never feel the need to use of a custom input method or keyboard layout: no standard layout has included that character on any platform. You can use any Android or iOS smartphone, even their tactile keyboard does not include it. Forcing its uses just makes the UI less user-friendly. If it's used, that just because of unjustified technical reasons, introduced on OTHER platforms than Android. And there's NEVER been any documented distinctive usage of the technical "ellipsis" being need and used distinctively in any language (and not those that were targetted by legacy terminals or printers, for inputting any text written in the Latin, Greek, or Cyrillic alphabets). Only East Asian texts (usnig CJK fonts) have a distinctive ellipsis, but which is encoded differently to behave like CJK sinograms with the East Asian metrics and alignment rules (including for their specific traditional vertical presentation: East Asian texts don't use it; as well Indic scripts use unrelated "danda" punctuations, and South East Asian or Armenian scripts their own symbols, just like they change the character for the full stop, which is not a dot at all, and where succession of multiple dots is not meant to have any "ellipisis" meaning but are just treated like dotted rules, e.g. to fill gaps between columns ni tabulated data where they have NO semantic by themselves but are just a visual presentation of whitespaces helping readers to follow lines, possibly by adding variable spacing between dots). But more genralyl many fonts even if they are proportional, make an arbitrary distinction, where dots are voluntarily reduced in size and gaps between them, which violates the traditional typography of all ellipisis occurences in normal texts meant to be read by humans (making them even less readable, especially on small smartphone screens if they have low DPI, and the UI is tuned to use font fonts: these "compacted" ellipsises become confusable with underscores or other dashes). For user accessiblity (including accessibility tools used by people with visual deficiencies) they just cause more problems. The only cases where the ellpisis is then possibly need, is when converting human text for use on consoles (e.g. in "man pages" within a terminal usnig monospaced fonts: such specific transform of 3 dots into a single character is done directly by tools preparing those man pages with a known target rendering environment (a legacy console; but not at all for modern printers or rendering in HTML or typesetting in PDF, where proportional fonts will be used and text flow will use liens of text with a varaible numebr of characters, just like what is required anyway with many scripts that are not readable at all with "half-width" character cells: this is the case with almost all Asian scripts, including East Asian CJK scripts that also need "full-width" characters, but as well many symbols, including modern "emojis").

In summary, there's never been any demonstrated need of the elippisis character in any human readable text written in normal Latin/Greek/Cyrillic alphabets, and notably on the Android UI. Kiwix should not need it at all and most users can't even use/input that unncecessary character. which was in Unicode only for compatiblity with old legacy charsets (that were designed to focus simple terminals used for some decennials of the 20th century starting in the 1960s but no longer needed, and that has never been used by professional typographs for printing books, papers, magazines, banners or advertizing). It's just a myth (like the myth that English requires two spaces after a full stop, something that was introduced in the 1950's for typists using old mechanical typewriters that did not support variable character widths to produce tons of administrative documents). The huge mass of documents generated on early computers, in the second half of the 20th century, before the UCS became prevalent (before Android even existed) is the only but major reason why the ellipisis remains present in the UCS! It is a compatiblity character, and it has never eclipsed the traditional ellipsis used by all seriosu typographs in printed books, newspapers, magazines (except to "mimic" the old look of administrative or technical documents, that also made serious oversimplifications of what was needed to represent correctly written human languages with a typesetting that was more legible and more accessible for humans, and more pleasant/faster/easier to read even if the subjects covered were complex).

Normal humans are not programming a machine or don't want to interact with machines, that are just necessary tools to interact with other humans (the machine should then make efforts to adapt to humans, not the reverse, and this is in that spirit that finally the UCS was designed, stop legacy technical charsets and allow better interaction, includnig in multilingual contexts, so French is not an exception, and humans will also want a choice of fnots, a choice of font sizes or styles to fir their needs, Android itself allows and favor such free choices in the UI of any application including Kiwix). Verdy p (talk) 18:24, 19 March 2023 (UTC)

Hi. Thank you so much for this enlighting answer. To me this leads to the few conclusions:

* This explanation should be put somehow in an article in TW, this is valuable for all softwares IMO.

* There is nothing which forbids the ellipsis character in SW or in TW, so I don't think it should be reverted (assuming we have it in the original string in English). This might be a bad practice, but this is the decision of the software developer. It should be respected.

* Better use "..." and investigate/fix any linting error if there is one in Kiwix Android. Kelson (talk) 14:56, 24 March 2023 (UTC)

You're wrong, the ellipsis (in whatever form it is encoded as a single or three characters, makes NO senses in all language or scripts, meaning that it MUST be translatable as anything else where appropriate, and it's not something that a developer can decdie jsut using assumptions coming from English typographic rules). All punctuations are language-sensitive, including languages written in Latin (see quotation marks, exclamation marks, question marks) as well as spacing rules, or the correct placement or absence with certain words (see US vs. British Oxford styles for the comma before a "or/and" coordination). Basic Latin punctuations are also inappropriate in Greek, Armenian, and many Asian scripts where they be misleading (or swapped in meaning). A developer workign for English can decide what he wants, but not for languages that he does not know but want to support at best according the target audience and not according to his desires and incorrect assumptions that all langauges can use the English pucntuation without problems. Verdy p (talk) 15:11, 24 March 2023 (UTC)

What you explained so far related to the ellipsis unicode character is valid in all languages as far as I understand. There is nothing special to French. Any reason why the ellipsis character would be "more wrong" in French than in English (actually the linter considers it wrong in a first place to not use it in English)- refnec - ? Does TW has any official regulation on this? Kelson (talk) 10:01, 25 March 2023 (UTC)

See also U+2026 (mapped on 0x85 in legacy ISO 8859-1), U+22EE and U+22EF; the character U+2026 anyway is NOT accessible in any standard input method in Android French, and has never been needed. The dot character is not suitable with all non-Latin scripts; all punctuation signs are replaceable and have different usage and meaning across languages. The fact that it exists in English is only for legacy reasons (use with monospaced fonts on old terminals, typewriters and teletypes), but it is not even needed in English and Android also does not feature it in English layouts; technically wheere it exists in fonts, it only using English typographic metrics, and you should know that French typographic metrics are different (and so to support Frnch metrics, we need to add other narrow non-breaking spaces around them. English has well has deprecated its typewriter rules; we no longer use it for normal UI display, and the Android display has never been suited to monospaced fonts, that are not accessible and ugly, only used by programmers, but there's also no usage of the ellipsis in the syntax of any legacy programming languages that existed before Unicode when they only supported 8-bit charsets, and even modern programming languages do not use it (simply because they are hard to type, and customized keyboard layouts are hardly supported in common IDE or code editors). Remember that we are not writing a program but text to be read in the UI by users, and that final users should be able to type and search. If we do know the target human language we are creating texts to be read by humans, we never need it in any Android UI. On the opposite, Asian texts cannot use it at all and will want to use something else that is not confusive, so thay may use U+22EE and U+22EF, or dandas. When an ellipsis is used to translate an heistation, there are other conventions, including replacing them by the equvalent of a comma, or a plain word, or some dashes. Dot-like characters are not universal for use as punctuation (notably Semitic scripts which require local changes or adaptations).

Developers may decide what they want for English, this implies no (or should not have any) requirement to use English punctuation in all human languages that don't like them or where these can cause confusion with existing puctuation or typographic rules or translation rules. Translating an UI should not be based in technical programming requirements that are NOT applicable to human text to be used in any UI. Humans are not reading a programming language or don't have to guess what is meant and should see the best typographic styles (not those inherited by old typewriters or old terminals in the second half of the 20th century. Human langues and typography has many centuries of traditions that have still not been abandoned by typesetters for printing books or papers, in a way that makes those texts unaccessible to most human users. Verdy p (talk) 12:14, 25 March 2023 (UTC)

"This explanation should be put somehow in an article in TW,"

Well in case there is, it should cite reputable sources:

The ellipsis character is what is called a "Compatibility decomposable character" and according to Unicode 15, p. 26-28, their use outside legacy systems are discouraged (some of them are even deprecated but not the ellipsis character). Thibaut (talk) 20:23, 3 May 2023 (UTC)

The ellipsis is a compatibility character, it is neither NKC nor NFKD that both map it to three full stops. "Conceptually, compatibility characters are characters that would not have been encoded in the Unicode Standard except for compatibility and round-trip convertibility with other standards." Verdy p (talk) 00:57, 4 May 2023 (UTC)

The two are easily confused, cf. Unicode 15, p. 26-28:

“The list of compatibility decomposable characters is precisely defined by property values in the Unicode Character Database […] Compatibility Character Vs. Compatibility Decomposable Character. In informal discussions of the Unicode Standard, compatibility decomposable characters have also often been referred to simply as “compatibility characters.” This is understandable, in part because the two sets of characters largely overlap, but the concepts are actually distinct. There are compatibility characters which are not compatibility decomposable characters, and there are compatibility decomposable characters which are not compatibility characters. […] The Unicode Character Database supplies identification and mapping information only for compatibility decomposable characters, while compatibility variants are not formally identified or documented.“

According to the Unicode Character Properties Database, U+2026 is indeed a Compatibility decomposable character: Decomposition_Type=Compat. Thibaut (talk) 08:39, 4 May 2023 (UTC)

tt

Hi,

You often maintain language category pages, such as Category:Siberian Tatar. Many, perhaps even all of them, use the <tt> tag, which is not recommended according to :mw:Help:Lint errors/obsolete-tag. Do you want to fix it? That page recommends several alternative tags. I don't have a strong opinion about which one to choose. Maybe <code>, but it doesn't really matter to me.

Going further, I'm not sure why do these pages use so much manual markup anyway. It should probably be a template. Amir E. Aharoni (talk) 07:19, 21 March 2023 (UTC)

That's not critical at all, HTML5 does fklly support it, even if their doc says that it may be replaced by kbd or code and wanted to deprecate it (I would not use code here due to the way it is rendered by default on MediaWiki). HTML5 docs says that this is for "semantic" reasons, but there's no specific semantic here that applies a significant distinction). So this is harmless and not a bug. I could have used "kbd" many years ago (when "kbd" was still not supported by many browsers), but what I did was just copy-pasting existing code. Fixing it would require now editing many categories (about ~2000), that's lot of work to do manually now, but a bot may eventually do it. But there will be no visible or semantic effects at all, so that huge work will just be useless. All that matters here is to render codes in a monospaced font to clearly show the language codes). It does not make any diference as well in the indexing for searching this site. If we took this into consideration, we would need to aplpy many other new HTML5 elements that are NOT accepted by Mediawiki (including the missing support for "thead" and "tbody" that is clearly missing and was ni HTML4 since much longer. My opinion is that MediaWiki may do that itself when transforming the wiki page into HTML, but it does not do that due to compatiblity with existing CSS stylesheets that may need them for selectors.

Using a template would add nothing, except adding complecity. Initially I had wanted to use some icon style, but there was not enough icons available for all needed codes and in fact it would have clutteered the rendered pages. the basic markup is just simpler and effective there for the purpose and there's nothnig to annotate when we just render a code that is immediately self explained by the language name just after it. Verdy p (talk) 08:25, 21 March 2023 (UTC)

It's indeed not critical for rendering the pages, at least for the next few years. However, it is already starting to show up on Special:LintErrors, and while it's also not a big problem by itself, it would be nice to keep it as clean as possible.

If you can make a template that would replace blobs of HTML and wikitext like '''<bdi>{{Languagename|sty|{{USERLANGUAGE}}}}</bdi>''' (<tt>sty</tt> : <bdi>{{Languagename|sty}}</bdi>) with something that would look more like {{Language category|sty}} in the category page's wikitext source code and apply it to a couple of pages, I can probably make a bot that does it in the rest of the pages. I know that you like templates and language category pages, and there are probably some things about them that you know better than I do, so it's probably better if you start it. Amir E. Aharoni (talk) 08:33, 21 March 2023 (UTC)

That's a solution. This was started a long time ago when this wiki was not organized at all and was missing various templates. I have created a few and mantained a few for the babel categories, or for the portal. I could have created one for main language categories (and in that case the "tt" element may be replaced by "kbd" if you wish).

However the "Linter" plugin on this wiki is still not working properly (it has added some pages but stopped working and its indexed pages are never reviewed later even when things are fixed). That's a separate bug you should work on to fix it. This will be more useful and better than running a bot, when all could be done manually, incrementally and with less risks. Verdy p (talk) 08:41, 21 March 2023 (UTC)

Yes, Linter doesn't work here fully yet, but I hope that some day it will, and it's good to get ready for that. If you can make that template, I can start thinking of mass replacement with a bot. I am reluctant to do it all by myself because some languages are simpler, like sty, but some may be more complex, and you know it better. Amir E. Aharoni (talk) 09:16, 21 March 2023 (UTC)

I've made such initial Template:Language category (and used it for English, French and Crimean Tatar). May be you'll want to add other info. That template expands to be a little more verbose and no logner uses "tt" but "kbd" to show the code. Verdy p (talk) 09:18, 21 March 2023 (UTC)

Thanks. I'll see what I can do. Amir E. Aharoni (talk) 13:25, 21 March 2023 (UTC)

It turned out to be quite easy. I replaced a lot of them, possibly all, although it's quite possible that I missed some. Can you please check?

I'm not sure what to do about Category:Test. Amir E. Aharoni (talk) 17:36, 21 March 2023 (UTC)

I have noted that you have run your bot (you started once and stopped it immediately due to an error, as it was forgetting the language code in the template inclusion, but you've reverted it and restarted it; all seems OK, though there may exist some subcategories for special variants).

May be there are a few others remaining (because there may be small differences that your regexp did not capture, e.g. if there were some different spaces, though since the beginning I tried to be consistant, but a small typo could make this possible). It can be fixed later when we discover them.

The code "test" is apparently used as a pseudo-code, there are a few others including "en-rtl" used in some Wikimedia projects that want to test the RTL layout using English terms, by tweaking the rendering of the Latin script using special style overrides, however this should not require specific translations, as it is just normal English rendered differently. Technically it is not conforming to BCP47, but it should not cause problems if we convert it, even if we add some extra notes after the template. It was used in 2020, but I can't remember for what; may be it can still be used again for the same purpose, most probably only temporarily, just to avoid polluting other localizations to true languages. The CLDR project or various Android frameworks also are also pseudo-codes for testing purposes by developers (e.g using some standard "qq*" private-use ISO 639-2, or private-use ISO 15924 script codes, or private-use ISO 3166-1 region codes, but there are local exceptions in some projects). Verdy p (talk) 17:51, 21 March 2023 (UTC)

Optional

Why do you submit unchanged copies of optional messages? Amir E. Aharoni (talk) 17:57, 4 April 2023 (UTC)

I'm checking those links and they redirect or use the HTTP instead of HTTPS. Some of these links are broken, I'll report them. Verdy p (talk) 17:59, 4 April 2023 (UTC)

OK, but why do you submit unchanged copies of optional messages? Amir E. Aharoni (talk) 18:01, 4 April 2023 (UTC)

This is part of the review, for target pages that are NOT translated and NOT translatable Verdy p (talk) 18:04, 4 April 2023 (UTC)

What target pages?

What does the translation of Osm:Html.dir/fr has to do with URLs?

Why do you submit unchanged copies of optional messages? Amir E. Aharoni (talk) 18:11, 4 April 2023 (UTC)

This will not change and is static constant for French. Other languages MUST "translate" it to change it to rtl, so it is not really "optional" and should be validated to disappear from the review list. Verdy p (talk) 18:13, 4 April 2023 (UTC)

Saying that it "should be validated to disappear from the review list" is complete nonsense. Only messages that were translated by another user appear on the review list. This was not translated by anyone, so it doesn't appear on the review list. Only RTL languages must translate it. Please stop translating it, and stop pointlessly copying unmodified optional messages. They are optional for a reason. Amir E. Aharoni (talk) 18:42, 4 April 2023 (UTC)

These message should be visible and not hidden when they need to be changed. Making them "optional" does not prohibit them to be edited, and they are visible in "untranslated" messages and counted as missing in statistics. So this makes sense (we want to reduce these counters to zero, and so we have to validate that they are correct, and OSM also needs that as well so they must pass the validation, even if OSM then can safely discards these automatically from their import tools, and does not depend on possibly diferent fallback rules not in sync for some languages). Verdy p (talk) 18:49, 4 April 2023 (UTC)

No.

They should be hidden, because for most editors, seeing them is confusing and unnecessary.

They are not visible in untranslated messaged, unless you specifically enable them.

They are not counted as missing in statistics.

OSM doesn't need them to pass any validation.

Stop doing that. Amir E. Aharoni (talk) 19:00, 4 April 2023 (UTC)

"de 1" au lieu de "d'un"

En 2019 tu avais mis pour toutes les dates, au singulier, "il y a plus d'un [mois, an...]" ce qui était parfait. Tu viens de tout changer pour mettre "il y a plus de 1 [mois, an...]". Penses-tu vraiment avoir amélioré les traductions ? Fred73000 (talk) 13:07, 8 April 2023 (UTC)

Note: tu ne précises pas pour quels messages ou projet, mais je suppose que c'est dans les groupes de messages OSM.

Ca a changé dans la source anglaise. Et il y a un problème en cours de discussion concernant la prise en charge des pluriels dans le projet OSM (ce ne sont pas des messages utilisés via MediaWiki mais par une autre extension de serveur web qui utilise un bibliothèque d'internationalisation bien plus simple mais qui ne sait pas encore prendre en charge correctement de nombreuses langues). En ce moement ces messages n'arrêtent pas de changer dans la source... Et au final on ne sait toujours pas ce qui va marcher ou pas. Ce qui marchait en 2019 peut-être pour le français ne marchait plus pour aucune langue depuis les changements, et même les chagnements en cours dans la version anglais sont incohérents, pour l'instant le français suit ce qui est fait dans la version anglophone. Verdy p (talk) 14:04, 8 April 2023 (UTC)

Note: ces problèmes font l'objet de toute une série de signalements depuis plusierus années, mais il y en a plus en ce moment et pour toutes les langues, ici ou dans le dépôt GitHub du projet OSM et d'autres espaces discussions OSM. Ils vient bien qu'il y a maintenant un problème et ont arrété leurs essais successifs. C'est le site web OSM qui manque d'une vraie prise en charge de la régionalisation (qui a toujours été bancale, y compris aussi sur son wiki, avec beaucoup trop de choses faites par des anglophones qui ne considèrent que l'usage britannique et ne comprennent pas encore qu'il y a nécessité de revoir tout ça dans un contexte réellement international). Des solutions ont été proposées mais les quelquies développeur britanniques refusent encore de modifier leur façon de faire et ne veulent pas revoir leur support des langues sur ses sites web, ni même développer quelques fonctions pour se conformer réellement aux usages pourtant bien documentés dans Unicode CLDR (la solution MEdiaWiki est compatible CLDR, et a quelques extensions en plus pour prendre en charge par exemple "d'un" et non "de 1" (mais le classificateur "one" dans CLDR en français désigne aussi la valeur "0", singulier lui aussi en français, pour gérer cette exception pour la valeur 1, seule la solution MediaWiki le permet, mais pas la solution actuelle utilisée par OSM qui ne semble pas en comprendre l'intérêt). Verdy p (talk) 14:07, 8 April 2023 (UTC)

Ok, merci, réponse très claire même si je n'ai jamais vu, sur OSM, pour les changesets où c'est utilisé et peut-être ailleurs, de dates écrites avec 0 (ce qui donnerait par exemple "modifié il y a plus de 0 mois par...", sic). Mais de toute façon, le 0 est (ou devrait être) géré comme le 2 ou +, d'après https://translatewiki.net/wiki/Plural :

• 1: form 1
• 0 and all other numbers: form 2

Fred73000 (talk) 15:02, 8 April 2023 (UTC)

"form 1" ou "form 2" ne désigne pas le nombre, c'est juste le rang, et OSM n'utilise même pas les rangs mais les symboles "one", "two", "few", "many", "other" etc. normalement issus de CLDR, seul Mediawiki utilise les rangs pour indiquer l'ordre imposé des formes (également GetText), tandis qu'il utilise des sélecteurs numérique explicite pour les exceptions à ces rangs. Bien que CLDR soit maitnenant très clair, le problème c'est que les différents outils de gestion des pluriels ne comprennent pas encore ce qui est dans CLDR et ce qui n'est pas dedans (notamment pas les exceptions pour des varleurs spécifiques dans MediaWiki qui permet par exemple de faire des exceptions pour non pas présenter les formes numériques, mais les mots des adjectifs numéraux par exemple de "un" à "douze", même en français alors que le français n'a que deux formes "form 1" pour le singulier (moins de 2, comprend donc zéro et un) et "form 2" pour le pluriel (en fait c'est la forme par défaut qui doit être la dernière indiquée et correspond au symbole "other" the CLDR et que *toutes* les langues doivent avoir pour afficher tous les autrers cas, y compris les langues n'ayant pas de forme grammaticale pour le pluriel).

Note qu'OSM ne sait toujours pas correctement formater les pluriels pour les langues qui ont besoin de plus de 2 formes, dont notamment les langues, celtiques, slaves et sémitiques, et qu'il y en a d'autres encore, avec des anomalies signalées en vietnamien par exemple, au delà des cas bien connus ici du russe de l'arabe et de l'hébreu, mais que les développeurs britanniques d'OSM ignorent complètement! ou ne comprennent pas correctement en faisant une lecture erronée de ce qui est décrit dans le standard CLDR).

Les développeurs de MediaWiki ont bien compris les besoins et les extensions pour les exceptions aux règles CLDR sont également permises par CLDR qui ne décrit que le support minimal nécessaire). MediaWiki manque encore d'autres choses pour la prise en charge de particularités à certaines langues (on a ici un bon exemple d'extension conforme à CLDR dans Freecol, masi on commence à en voir se développer pour le Wikipedia multilingue en cours de création et d'évaluation à commencer par Wikifonctions en plein chantier, et par Wikidata avec les entrées lexicales et sémantiques) Mediawiki a déjà intégré la prise en charge enfin correcte de BCP 47, mais il reste à le finaliser pour les wikis de Wikimedia où il reste encore des cas bien connus de non-conformité. La suite sera la prise en compte d'autres propriétés sémantiques, lexicales et morphologiques (par exemple la gestion d'attributs pour les termes traduits leur permettant de les réutiliser et de les adapter dans d'autres messages ou textes: règles de capitalisation, de mutation contextuelle, d'agglutination, de séparation ou déplacements de termes ou particules: c'est possible et Freecol montre là aussi le chemin à suivre.

En revanche je ne comprend pas la résistance d'OSM pour gérer correctement au moins les pluriels. Verdy p (talk) 16:16, 8 April 2023 (UTC)

Merci pour cette longue explication mais cela ne répond pas à ma question. J'ai très bien compris form 1 et form 2. Form 1 s'applique pour le nombre 1 et form 2 s'applique pour le nombre 0 et pour tous les autres nombres (2, 3, 4, 10, 100, etc), décomposition qui est utilisée pour l'anglais. Cela tombe bien, cette décomposition en 2 form est parfaite quand on veut traduire de l'anglais vers le français. Que cette règle ne marche pas pour l'hébreu, tu m'excuseras, mais ce n'est pas mon propos, je ne traduis pas en hébreu. La traduction que tu avais faite en 2019 reste donc pour moi la meilleure et ta traduction récente est clairement moins bonne. Et m'expliquer que ta nouvelle traduction d'un texte particulier anglais d'osm est justifiée par un problème de traduction de l'anglais vers le vietnamien, désolé, je ne vois pas le rapport. Fred73000 (talk) 16:09, 15 April 2023 (UTC)

Le problème des traductions sur les autres langues est à l'origine des modifs en cours (qui ne marchent toujours pas) sur OSM concernant ces messages pour lesquels ils ont changé plusieurs fois la solution. L'ancienne solution ne marchait plus, ils ont tenté de changer les messages à traduire, puis fait marche arrière pour d'autres. Le problème est qu'on ne sait toujours pas ce qui sera la solution stable, même en français (qui ne suit pas exactement la même règle que l'anglais, pour lequel il n'y a jamais eu de problème). Le problème est là: les développeurs d'OSM n'ont pas encore compris ce qu'il fallait faire et ont mal lu les spécifications de CLDR qui pourtant explique cela (notamment le cas du zéro qui est le cas le plus courant dans de très nombreuses langues et qui n'est pas géré correctement). Il y a bien une discussion en cours sur le github d'OSM avec un bogue toujours pas résolu. Mais ce qu'ils ont essayé de "bidouiller" pour certaines langues ne faisait plus marcher correctement les autres. Donc dans l'immédiat ils ont demandé qu'on affiche directement la valeur numérique sans la traduire en lettres. Ca propduit donc "de $1" qui donne "de 0", "de 1", "de 2", etc. et on ne peut plus avoir "d'1", ni utiliser "d'un" pour le singulier qui ne saurait plus distinguer le zéro utilisé dans les mêmes messages. Verdy p (talk) 02:18, 16 April 2023 (UTC)

Justement non, en français si on a des mots qui s'orthographient différemment au singulier et au pluriel, la forme 1 (singulier) doit s'appliquer aussi au 0, et pas du tout la forme 2 (pluriel). Sinon on obtient par exemple "0 ans" ou "0 points" (ce qui est incorrect en français) au lieu de "0 an" ou "0 point" (ce qu'on doit obtenir). Et cela doit être vrai aussi pour les traductions dans OSM (qui ne doivent pas se contenter de règles simplifiées juste taillées vite fait pour l'anglais et totalement inadapté à d'autres langues ayant aussi besoin d'autres formes (jusqu'à 6 pour les langues actuellement prises en charge ici, ou dans Mediawiki, ou dans CLDR, et qui peuvent aussi traiter 0 dans un cas séparé du singulier et des pluriels simples). Rien que pour le russe déjà (ou les autres langues slaves, celtiques et sémitiques) les règles anglaises simplifiées serait fausses. C'est sans doute la description ou documentation en anglais qui est trop simplifiée et ne reflète pas la réalité de ce qui est déjà fait ou devrait l'être dans d'autres langues. Et en tout cas pour les règles CDLR c'est faux. Verdy p (talk) 11:37, 17 June 2023 (UTC)

Traduire Lingualibre en wls

Bonjour Verdy, merci pour ton aide sur SignIt, le système d'enregistrement vidéo vient d'être réparé. Voir Commons.

Par ailleurs, cotécôté Lingua Libre audio.... un nouvel utilisateur souhaite traduire l'interface du Francaisfrançais vers le fakaʻuvea (wls). Pour traduire de en→wls , c'est ici. Je ne parviens pas à trouver fr→wls . Avons-nous un lienslien pour forcer le francaisfrançais (ou une autre langue) en entrée ? Bien à toi. PS: réponse courte bienvenue, profites-en pour te faire un chocolat chaud :) Yug (talk) 16:18, 25 April 2023 (UTC)

Le wallisien a la traduction déjà activée ici. Voir Portal:Wls (où il y a déjà "Lea.Fakauvea" inscrite, qui participe aussi à la traduction française ici depuis longtemps au moins en relecture).

Le terms faka'uvea est le nom natif de la langue appelée wikipedia:fr:wallisien en français (parlée nativement à Wallis-et-Futuna).

Je ne vois pas ce qui manque ici, sauf peut-être l'activation sur Wikipedia (mais il a au moins un incubateur activé, où l'interface MediaWiki peut être testée en wallisien). Mais le plus gros du travail reste encore sur l'interface MediaWiki de base avant de pouvoir utiliser Lingua Libre dessus. En attendant c'est normal que ce ne soit pas accessible dans Wikimedia Commons par exemple, car le wallisien n'y est toujours pas exporté si le niveeau de complétion n'est pas suffisant. Ce n'est alors pas ici qu'il faut faire la demande d'activation au moins sur Commons (pour l'interface utilisateur) si c'est ce que tu cherches. Mais rien ne bloque l'export sur l'Incubateur Wikimedia.

Je crois sinon que tu pensais qu'on peut traduire du français vers une autre langue. En fait non, la source reste toujours ici l'anglais. Si on traduit vers le wallisen (en→wls) l'anglais est affiché en haut mais le français déjà complet doit être proposé dans le panneau de droite lors de la traduction ici.

Le wallisien devrait aussi être réglé pour utiliser le français comme langue de repli ou fallback dans MediaWiki, plutôt que l'anglais par défaut, si ce n'est pas le cas, il faut en faire la demande sur Wikimedia MetaWiki ou dans Wikimedia Phabricator.

Mais cela ne change pas la source de traduction qui reste ici l'anglais, mais le français peut être sélectionné par tout traducteur comme langue d'aide. Je pense que c'est le cas déjà de l'utilisatrice "Lea.Fakauvea' mais si ton nouvel utilisateur n'a pas bien réglé sa langue de base, il peut avoir oublié d'ajouter (dans le panneau de préférences) le français comme langue d'aide à la traduction. On ne peut pas traduire ici directement de français en wallisien, uniquement de l'anglais en wallisien (mais en disposant du français comme langue d'aide).

Dans les "Préférences" de l'utilisateur (menu en haut de la page), voir l'onglet "Modification" : il y a une zone dédiée pour indiquer une liste de langues préférées pour l'aide à la traduction, ce qui permet de voir les traductions déjà disponibles dans d'autres langues que l'anglais; il suffit d'y inscrire "fr" dedans (par exemple on peut indiquer "fr, en, de, nl, pt, es, ca, eo, it, la") et les messages traduits en français seront listé dans l'interface de traduction, si l'utilisateur en question maîtrise mal l'anglais; le français est à priori très bien relu par plein de monde (le français a été la toute première langue traduite ici à 100% et relue à près de 60% voire plus pour les modules importants, même si certains messages sources en anglais changent souvent et obligent à les retraduire ou corriger sans que ce soit encore relu). Le français peut aider les traducteurs à clarifier les termes anglais parfois ambigus, car la plupart de ces difficultés ont été résolues et le français distingue plus clairement les noms des verbes, ajoute des conjugaisons utiles, et relève ce qui est les noms propres à ne pas traduire). Verdy p (talk) 19:04, 25 April 2023 (UTC)

Il manque encore quelques messages de Lingua Libre SignIt à traduire pour le finnois [fi] et surtout pour le bengali [bn] qui est une des plus grandes langues du monde. L'hindi [hi] est déjà traduit, de même que persan [fa] mais ce serait bien d'avoir aussi l'ourdou [ur] qui est quasiment la même langue "hindoustani" que l'hindi (mais écrite en alphabet arabe au lieu de la dévanagari). L'ourdou incorpore aussi des emprunts au persan qu'on retrouve aussi en hindi une fois translitérés en dévanagari, ce qui n'est pas une hérésie car ce sont toutes les 3 des "langues indo-iraniennes", le persan étant beaucoup plus proche de l'hindoustani (hindi / ourdou) que de l'arabe (qui est une langue sémitique, rien à voir avec les langues indo-européennes, dont font partie les langues germaniques, celtiques, italiques et indo-iraniennes; le yiddish n'est pas une langue sémitique même si elle est écrite en alphabet hébreu, c'est une langue germanique très proche de l'allemand, mais aussi de l'anglais et du français, lequel a fait de nombreux apports en anglais et en allemand mais aussi en yiddish notamment en Alsace, Suisse et en Provence, ainsi qu'en Algérie française chez les Juifs ashkénazes avant l'indépendance; depuis la création d'Israël, le yiddish en Europe est de plus en plus proche de l'allemand, alors qu'en Israël le yiddish emprunte beaucoup plus à l'hébreu et à l'arabe, ce qui mène à une dichotomie dialectale du yiddish entre le yiddish oriental, plus sémitisé, et le yiddish occidental, plus germanisé). Verdy p (talk) 20:00, 25 April 2023 (UTC)

Bonsoir Verdy, content de te lire, j'apprends plein de choses.

Je transmets cette discussion à Frank. Je note egalementégalement pour le bn et l'ourdou, c'est une bonne ideeidée. Si tu es sur Paris ou mobile, regarde le « full program » (pdf) de meta:ContribuLing 2023/Program. CaÇa devrait te plaire. J'y serai ! Yug (talk) 21:28, 26 April 2023 (UTC)

Norme ou standard ?

Pourquoi préférer « standard » à « norme » ? Urhixidur (talk) 12:01, 28 April 2023 (UTC)

Parce que dans le cas présent ce n'est PAS une norme, mais juste un standard pour une application spécifique et pas réellement établi par des décisions et pas applicable ailleurs. une norme nécessite un comité de normalisation, des délibérations, un registre des décisions, et on ne la change pas uniléralement. La norme établit également des contraintes (en terme de niveau de conformité) et on peut aussi s'y référer. La norme est également datée ou versionnée, elle cite ses références requises ou informatives. La norme fait l'objet d'un processus de décision, et de droits nécessaires pour voter, le système de décision est bien cadré, même si la norme prévoit une ouverture par des enquêtes ouvertes au public et des appels à contribution. Ici on est très loin de tout ça. Verdy p (talk) 14:37, 28 April 2023 (UTC)

RecordWizard

Bonjour Verdy,

Je passe te signaler des changements à venir coté RecordWizard. Je vais modifier les textes anglais pour prendre en compte les langues signées. Je vais donc réfléchir à des alternatives à "speaker", "voice", "audio", "microphone", etc. C'est normal. Bien à toi. Yug (talk) 19:46, 2 May 2023 (UTC)

Ne t'inquiète pas je suis les changements régulièrement sur touts les projets et je ne manquerai pas de traduire ce qu'il faut le moment venu. Je suis les traductions à peu près tous les jours (souvent plusieurs fois par jour). Verdy p (talk) 19:48, 2 May 2023 (UTC)

Tu as vu le Wikicamp 2023 du 7 au 9 juillet 2023 à Narbonne ? Les transport en commun sont remboursé pour les membres de Wikimédia France (12€). Yug (talk)

Je ne suis pas membre de Wikimédia France, et je ne peux pas aller à Narbonne (dans les deux cas, faute de moyens depuis des années, je n'ai que mes jambes ; les bus sont gratuits pour tous, toute l'année et sur toutes les lignes partout dans l'agglomération de Niort). Verdy p (talk) 19:59, 2 May 2023 (UTC)

Le train de Niort a Narbonne est remboursé (pour les membres) :) Yug (talk) 21:06, 2 May 2023 (UTC)

Peut-être mais je n'ai même pas les moyens d'avancer les frais, et encore moins de me loger sur place au moins un soir avec 100 euros par semaine pour tout (alimentation, téléphonie/Internet, habillement, assurance, etc. hors loyer et charges locatives). Déjà j'ai bien du mal à juste me payer un verre par semaine, et je ne vais jamais au restau depuis des années, si je n'ai plus de voiture c'est faute de pouvoir l'entretenir, j'économise en ce moment pour m'acheter un frigo et un four et je n'ai pas droit au crédit (même si je n'ai jamais eu aucune dette) et mes prochaines lunettes en fin d'année (car insuffisamment remboursé, elles ont déjà 7 ans et ne sont plus adaptées à ma vue qui change). Verdy p (talk) 21:17, 2 May 2023 (UTC)

J'en reçois des invits : Narbonne, Paris un peu plus haut (message de Yug sur LinguaLibre SignIt en langue wallisienne) ! Mais là encore pas mes moyens. Avant je pouvais, plus depuis quelques années pour des raisons de santé. Je fais de mon mieux mais trop souvent à distance, car je n'ai personne intéressé à collaborer à proximité de Niort. Verdy p (talk) 22:49, 2 May 2023 (UTC)

[EDIT] Pour info : le transport, l'hébergement (vendredi à dimanche) et les repas (vendredi à dimanche) sont pris en charge par Wikimédia France (si l'organisation est comme l'année derniere) pour les membres (12€, sauf situation particulière). Pour le train, des avances sont possibles. Je viens de vérifier les trains, c'est long : aller de 7h00 et 90€ environ. Pas évident. Je te transmets ces informations pour "un jour", lorsque cela te tentera. La communauté gagnerait en tout cas à avoir davantage de wikimédiens "de terrain" au Wikicamps. (Il y a un bon quart de wikt:grenouilles de bénitier comme on dit chez nous ! Toujours aux réunions, rarement sur le terrain !) Yug (talk) 07:58, 3 May 2023 (UTC)

Note: je n'y serai pas cette année. Yug (talk) 06:49, 4 May 2023 (UTC)

Données EXIF

Bonjour,

Pourquoi supprimer la majuscule initiale de tous les messages en français dans Special:PrefixIndex/MediaWiki:Exif ?

Tous les champs de la première colonne dans les tableaux EXIF en dessous de chaque fichier (comme ici) commenceront par une minuscule au lieu d'une majuscule. Thibaut (talk) 18:45, 3 May 2023 (UTC)

C'est dû à un bogue signalé dans le support, et je ne m'en suis pas aperçu tout de suite: les sources affichaient des minuscules initiales. Verdy p (talk) 14:29, 4 May 2023 (UTC)

Justification ou cadrage ?

À propos de ce changement, la doc fait mention de la commande LaTeX \cfrac, comme dans cet exemple. Me semble que c'est bel et bien de la justification que les arguments [l] et [r] permettent de faire. Qu'en penses-tu ? Urhixidur (talk) 01:36, 5 May 2023 (UTC)

La "justification" ne désigne strictement jamais le cadrage à droite ou à gauche ni le centrage. Ces types "d'alignement" (terminologie anglophone du HTML) sont tous mutuellement incompatibles entre eux et le français est clair à ce sujet: on ne peut pas justifier à droite, ni à gauche, ni au centre. Cependant la justification est possible conjointement avec le cadrage (qui ne s'applique qu'aux lignes finales incomplètes d'un paragraphe justifié, la justification ne concernant que les premières lignes complètes). L'anglais de la doc LaTeX que tu cites n'est pas assez clair, et n'est certainement pas une référence pour traduire en français !

D'ailleurs même en anglais, les termes "justified" ou "justification" ne sont jamais utilisé pour le cadrage, communément appelé "alignment" dans les doc en anglais du HTML, de CSS ou de LaTeX.

Donc je pense que tu fais des confusions et que tu comprends même mal l'anglais et fais des extrapolations hasardeuses sur ces sujets.

De même la confusion entre "cadrage" (qui s'applique au contenu textuel normal) et "ferrage" (qui s'applique aux éléments flottants placés le long de la marge de sorte que le contenu normal est décalé et ne colle plus aux marges mais seulement au plus près des éléments flottants, tels que les illustrations ou lettrines initiales, le contenus des éléments flottants ayant leur propre cadrage interne). Verdy p (talk) 01:53, 5 May 2023 (UTC)

Je citais la doc de LaTeX pas pour son anglais mais pour montrer l'effet des paramètres. Urhixidur (talk) 12:35, 5 May 2023 (UTC)

MediaWiki:Newsletter-edit-subscribers-nochanges/fr

Ce ne sont pourtant pas les abonnés qui sont modifiés. La « liste des abonnés », peut-être. « La liste des abonnements » a naturellement pour ellipse « les abonnements », mais on ne peut en dire autant de la relation entre « la liste des abonnés » et « les abonnés ». Urhixidur (talk) 01:25, 7 May 2023 (UTC)

Signale le alors aussi pour l"original en anglais ! D'ailleurs ce ne sont pas les abonnements eux-mêmes qui sont changés. Et encore moins la liste des abonnements (de l'utilisateur). Verdy p (talk) 06:08, 7 May 2023 (UTC)

J’ai changé en « liste des abonnés » comme ça c’est plus clair et tout le monde est content (d’ailleurs c’est ce que dit le /qqq de toute façon). Thibaut (talk) 08:52, 7 May 2023 (UTC)

Je suis d'accord et j'ai approuvé. Verdy p (talk) 09:13, 7 May 2023 (UTC)

Getting into unrelated discussions

You've been asked many, many times: stop getting into other people's discussions and writing unrelated walls of text. The next time you do it, you'll be blocked indefinitely. Amir E. Aharoni (talk) 07:30, 11 May 2023 (UTC)

You've replied yourself unrelated to the additional question, you initially asked. It may irritate yourself, but it was not unrelated at all given what you wrote. And I did not disagree at all with your remarks, even if you both confused the initial topic. And I did not contradict that person you were asking, but added some reasons explaining why the pipe separators was possibly translatable, as well I did not contradict you about why the Bidi control was not needed for this separator. My reply was not much longer than the two replies (can't be qualified as a "wall"), given that it finally recenters your question to the initial topic on the separator (from which you derived yourself)! May be you d'ont want to discuss on this site, but prefer inundating other talk sites like Telegram (with tons of messages posted there, many of them forward multiple times from other sites as well, most of them notifications). Verdy p (talk) 08:21, 11 May 2023 (UTC)

Language name of Saraiki

Language name of Saraiki on the main menu is Written as

• دیرہ Saraiki (Arabic script)
• ترجمے Saraiki (Arabic script)It is requested that it Should be
• سرائیکی دیرہ
• سرائیکی ترجمے Portal Saraki Translations Saraiki Kindly correct these.

Saraiki (talk) 16:47, 16 May 2023 (UTC)

Yes buit the script code is important and used in translations), even if you think this is the default, it is not. So translating the name for "skr" and for "skr-arab" must be different (like for every other languages that use suffixes for variants).

And this does not affect any "'menu". The portal:Skr itself does not need that precision. I don't know the reason why no default script was chosen by Wikimedia, but likely it is caused by the alternate Devanagari script and they wanted to be clear about which script to use. Verdy p (talk) 16:51, 16 May 2023 (UTC)

Yes ,but these name be in Arabic script, not in Latin. Saraiki (talk) 17:02, 16 May 2023 (UTC)

And that's exactly what they are! If there's a missing translation for the script name, it can be fixed, either in the templates giving generic script names shown between parentheses (it may display fallbacks if there's no such translation provided), or directly in the language variant itself (see examples like Chinese where there are common forms for Simplifid and Traditional variants, and many other scripts that have multiple scripts).

Note I gave mention of Multani (which was actively used historically and is apparently still used for cultural purproses, along with other Landha scripts like Gurmukhi; Devanagari seems to have been used before the separation of India and Pakistan, but may still be used for Saraiki-speaking miniorities in India). 17:05, 16 May 2023 (UTC)

Also note that portals do not just give the autonym, but also the translation of language names in the current user's language. So if your current user language is English, uo'll see BOTH the autonym in Saraiki (with the translated script precision if there's one) and the translation in English. In all cases, we show the variant in the displayed name if there's a variant in the given code. Verdy p (talk) 17:15, 16 May 2023 (UTC)

Thanks for adding Multani. But it is no longer in use. Please translate the required string. or send me the link of string for the name of language. In Translations Arabic script be used. Saraiki (talk) 17:34, 16 May 2023 (UTC)

And the Arabic script IS used ! Don't you see it? (Note that eevn if you think you don't need Multani, other people may want it for their cultural projects or because they live elsewhere in a minority; this wiki and Wikiemdia has much spaces for minorities, they can work with their prefered variants, as long as not eveything is mixed). Verdy p (talk) 17:34, 16 May 2023 (UTC)

Ok, Thanks. Please translate

Saraiki (Arabic script) as سرائیکی Thanks again

Saraiki (talk) 17:41, 16 May 2023 (UTC)

What you want is to translate "Saraiki (Arabic script)" [skr-Arab] as if it was just "Saraiki" (which is for [skr] alone). Removing the variant precision when the code specifies it is not an option. The portal [skr] already display "سرائیکی" in its title (independantly of the variant because the portal page is independant of it). This would be very unique for that language and would contradict the Wikimedia Language Commitee to keep this precision, even if today for moden use in Pakistan, almost everyone only uses the Arabic script, this has not been the case everytime, and it is still not the case everywhere (there are still publications made with Multani, and some revival efforts so that old books can be read as they are part of the culture heritage, and linguists, historians and hobbyists that want to look into these old scriptures, including for fact checking or with legal disputes, or when there are disagreements about some modern translations about the meanings of original texts, or for enriching the modern languages based on solid historical grounds rather than direct borrownings from unrealted languages). Verdy p (talk) 17:58, 16 May 2023 (UTC)

Wrong name in Romanian

Hi, In Romanian is in Crh-RO written "turcă crimeeană (Romania)", but mostly is known as "tătară". I will write here the name "Romanian Tatar" in [ro] and [tr], maybe you can add them too:

• Romanian — tătară (România)
• Turkish — Romanya Tatarcası

Zolgoyo (talk) 12:28, 17 May 2023 (UTC)

These were not "wrong", just not defined, so they displayed a fallback name in another language (English most of the time, unless there's a better fallback rule). Not all language pairs are treated (imagine: 7000 languages by 7000, not including variants, this gives about 49 millions names to define). only some common pairs are defined in these templates for each language: the autonym (and names in variants of the same langauge), names in (English and French (as they are in various ISO standards), adn some other common pairs relevant for that language (like here between Crimean Tatar and Turkish or Romanian... but then why not Gagauz, Greek, Bulgarian, Ukrainian, Russian?) Verdy p (talk) 15:08, 17 May 2023 (UTC)

I can write you also the name "Romanian Tatar" in languages, which has connection with Romanian Tatar. And in Turkish it is called "Romanya Tatarcası", it's also possible to see in trwiki, because "Tatarcası (Romanya)" is not correct. Also in Romanian is written "turcă crimeeană" (Crimean Turkish) for Crimean Tatar, but mostly used is "tătară crimeeană".

Russian — татарский (Румыния)

Ukrainian — кримськотатарська (Румунія)

Kazakh — татар тілі (Румыния)

Bulgarian — татарски (Румъния)

Greek — Ταταρικά (Ρουμανία)

Gagauz — Romanya Tatarcası (same name like in Turkish)

Otherwise say me if something is missing. Thank you for your help! Zolgoyo (talk) 16:21, 17 May 2023 (UTC)

Special:Diff/11624702

Bonsoir,
Justement quoi ? Quel terme générique ou écriture épicène me parlez-vous ? Avez-vous lu mon résumé, car ce n'est pas du tout ce que j'exprime ?
Voici ce que j'écris :
L'authentification peut se faire sur plusieurs projets. Généralement, il s'agit de Meta. Donc si j'écris https://meta.wikimedia.org/wiki/Utilisateur:Eihel (remarquez le « Utilisateur »), ça ne fonctionne pas. Par contre, si j'écris https://fr.wikipedia.org/wiki/User:Eihel (remarquez le « user »), ça fonctionne, car Mediawiki va rediriger vers le bon compte. De plus, il n'y a pas à ajouter l'espace insécable et l'espace autour de :, puisqu'il s'agit de ressembler à une URL, comme l'exemple ci-avant. Si on veut s'authentifier sur le serveur WikimediaZA (où je suis modo), il va, par contre, ouvrir un lien vers enWP avec un jeton et une clé. Donc il s'agit bien de user:. Du coup, il n'y a pas besoin de forme féminine non plus, cqfd.
Je trouve pénible la correction, puis la relecture sans cesse parce que vous souhaitez imposer votre POV, alors que vous ne semblez pas faire partie des médias concernés. Des personnes se sont plaintes des mauvaises traductions à l'époque déjà et j'ai pris la peine de corriger cela, mais vous venez tout chambouler encore et encore. Cette page et d'autres pages de WikiAuthBot n'ont pas besoin de correction supplémentaire en français. Merci.
Cordialement. Eihel (talk) 21:10, 30 May 2023 (UTC)

Ce n'est pas un lien ici, le terme User est à traduire (comme dans les autres langues) car c'est un libellé visible, ce n'est pas un point de vue du tout! Vouloir imposer un lien là où il ne peut même pas y en avoir un valide ici! WikiBotAht sert à s'authentifier avec des services non wiki en plus! Le message indique juste avec quel nom d'utilisateur du wiki local le service externe s'est identifié en utilisant l'authentification d'un compte externe (et qui n'est pas non plus chez Wikimedia, donc pas du tout sur Meta). L'outil n'a rien à voir non plus avec la connexion unifiée (Unified Login System) qui permet de s'authentifier une seule fois sur un des wikis de Wikimedia et passer de l'un à l'autre si on a un compte unifié.

Bref rien à voir avec un lien wiki, ni même Wikipédia, c'est générique pour tout wiki et toute langue, même hors de Wikimedia (par exemple Miraheze, BlueSpice ou Fanzone). Sinon pourquoi il y aurait le texte "authenticated as" au début et aucune syntaxe de lien juste après? La ponctuation n'a rien à voir non plus avec un espace de noms, le mon user pourrait être ailleurs, le deux-points remplacé aussi par la ponctuation appropriée à l'écriture de la langue traduite; regarde les autres traductions validées, là tu veux changer ce qui a été validé depuis longtemps en faisant une fausse interprétation. WikiBotAuth n'est même PAS une extension de MediaWiki, c'est un outil tiers hébergé ailleurs. Verdy p (talk) 00:39, 31 May 2023 (UTC)

D'ailleurs lis la description du projet qui dit "WikiAuthBot est un robot de Discord qui authentifie les utilisateurs de Discord sur leurs comptes Wikimedia ou Miraheze." Le but est de faire une liaison entre les comptes Discord et Wikis.

Rien à voir non plus avec les "comptes confirmés" internes au wiki (et qui existent sans faire appel au moindre service tiers, juste avec un seul compte wiki, et même pas valide sur tous les wikis de Wikimedia mais un par un, et indépendant du fait qu'on y soit connecté avec un compte unifié avec SUL ou pas) : c'est un statut strictement local du compte pour le wiki Mediawiki, géré accordé soit automatiquement en fonction d'un nombre de modifications et d'un temp minimum après l'inscription ou accordé/retiré par un admin du wiki et strictement jamais par WikiAuthBot.

D'ailleurs la syntaxe prise en charge par ces message n'est pas celle de MediaWiki, les variables substituées sont généralement représentée entièrement en capitales (l'outil lui même fait une simple substitution de chaine sans aucune délimiteur, ne prend pas en charge les italiques/Gras de Mediawiki, ni les liens par URL et les wikiliens. L'outil est écrit dans un autre langage, ne tourne ni sur les serveurs du Wiki ni sur ceux de Discord, et il est géré par un petit groupe chez Discord, qui se contente de fournir les clés d'authentification Discord et les lier aux clés d'authntification des wiki (on ne sait pas trop où cet outil stocke les clés, mais apparemment cela utilise un protocole à jetons de hachage du genre OAuth, et une durée maximale de validité; ni Mediawiki ne connait les comptes Discord et comment s'y connecter, ni Discord ne connait les comptes de Wiki et comment s'y connecter: l'utilisateur doit s'identifier sur les deux et cela génère un jeton numérique unique pour cette association; on peut retirer cette association définitivement et en recréer une autre plus tard, sans avoir rien changé aux comptes du wikis et de Discord). Rien à voir avec Meta non plus.

Plus de doc ici : "https://meta.wikimedia.org/wiki/Discord#WikiAuthBot"; il fonctionne comme une extension de Discord développée avec son kit (et non une extension de MediaWiki); le projet est écrit en Python sur "https://github.com/1VORK/WikiAuthBot/".

Bref je n'ai rien chamboulé du tout, c'est bien toi qui vient de casser et réinterpréter ce qui a été validé dans toutes les langues et depuis plusieurs années. Verdy p (talk) 01:03, 31 May 2023 (UTC)

User page edits

Why are you doing these edits to user pages with very complex HTML? Such as:

• https://translatewiki.net/w/i.php?title=User:Denayadennis&diff=prev&oldid=11643397
• https://translatewiki.net/w/i.php?title=User:ArsenalBastion4093&diff=prev&oldid=11643374
• https://translatewiki.net/w/i.php?title=User:Anonymoususer12321&diff=prev&oldid=11643384

Did these people ask you?

(In case you wonder, I add the "high prio links" templates to people's pages because they ask me.) Amir E. Aharoni (talk) 07:22, 8 June 2023 (UTC)

They did not ask you, you just created these pages for most users that just get authorized, and still that never did anything except passing a sandboxed translation test, before they started doing anything on the wiki. None of these users asked you for that before you posted a large bunch of links of your choice (without any form of presentation effort) on their user pages, filling these pages completely before they could add their own introduction there. And what is complex HTML: a "div" and using the babelbox? Adding a subtitle? Note that in many cases you added these links without specifying about what they were related to (which language), when all translators should speak several ones (and not necessarily very well English, but enough from another major language used as a helper in the TranslateUI, or just one because they just need to fix a typo in their own native language, or just perform linguistic reviews, according to discussions that occured elsewhere). Verdy p (talk) 07:32, 8 June 2023 (UTC)

OK, I understand.

Stop doing that. Amir E. Aharoni (talk) 08:28, 8 June 2023 (UTC)

But then you shoud stop yourself posting huge lists of links on user pages of users that you just authorized, and adding babel boxes automatically for them (you don't really know their language level, sometimes you've added English in these boxes as if it was native, when users can only read it but won't translate into it)... I understand that you wanted to help these users, but what I added was MUCH more minor and still helpful (and it was based on what they really did, according to their recent history). What you added yourself in these pages, without these users demanding it, was much more complex and was not necessarily their priorities. Just like you, I wanted to help but with a much smaller content which is still readable and easily maintainable (e.g by adding more userboxes without creating a huge verical column that could push the user contents much lower on the page).

Also you should be more careful at the presentation of these huge lists of nks if you wanted to be really user-friendly (but you did not accept the minor fixes I made to the template you post: apparently you don't like HTML at all, even if its very basic and does not alter the content of lists that is still easily editable and equally readable; may be then you don't like HTML and the Mediawiki syntax itself?).

IMHO, you should just post these links in a section of their talk page (not by transclusion but by substitution, so that users can select what they are interested to see on their user pages, and then purge/archive their talk page), and let then users organize and select what they'll want to see in their user page that tyou use as if this was a talk page for posting contents that you can constantly change at any time, even if these changes are not relevant to what these users are doing, or they do not need most of these. Note that for that, there's a "Welcome" message to be posted on talk page, why don't you use it, when it's possible to include a link to some hint page created and maintained collaboratively and not just by you at your own choice? Verdy p (talk) 08:34, 8 June 2023 (UTC)

They did ask me. You cannot know about all the conversations I have with users.

Your edits have included a very complex and repetitive HTML and CSS. It should have been in a template if it was needed at all, but it is not needed in the first place. Amir E. Aharoni (talk) 09:04, 8 June 2023 (UTC)

A template with variable parameters for the list? when all it does is to include a small prefix and a small suffix to the babelbox, which matches the documentation of babelboxes. There's no specific benefit for the template that would be so basic. And for information, some projects are supported some are legacy and no longer supported actively, so there may be two sections, but not all the time. I did not add random projects, just those that users really contributed to (I checked thei history, and you'll note that msot of them do not follow your long todo-list as it's not their priority and current tasks). And I seriously doubt you talked to all the users to whom you post these links, in a row just some seconds after you authorized them as new translators. I've seen various users deleting these additions when they just come back. But none reverted the list of projects that better fitted in their user page than the long vertical list. Making them horizontal allows them to add more projects at anytime with ease by adding a few characters, without breaking the general layout and usability of their page where they can manage their own todo lists and update their presentation and other lists of interests, or post relevant links to contact them somewhere else. So my edit was more relevant to what user really do than what you post to them in an inappropriate place which is not useful for other users interested in looking at user's contact, user's goals, user information: those links should better be in a separate page. May be it's time to deploy instead a sharable and reusable todo list, that users could then selectively enable/disable or mark as beign worked on, or tracked. Your list just matches what you are doing and following across all projects (but most users are much more focused on specific goals). Verdy p (talk) 09:14, 8 June 2023 (UTC)

Phabricator:phabricator-differential-6460d582d763636d/en

Hi, Verdy. This message seems to be incorrect. Could you please fix it? --Eleassar (talk) 18:11, 8 June 2023 (UTC)

Help request

Hi! I want a alphabet converter for crhwiki. There is alphabet Converter in crhwiki, Cyrillic and Latin, this one should to be Latin (Romania). By the way, it should not be hard, because the difference are only the letters Ĭ and W. And I don't know what I need to do, can you help me there? Zolgoyo (talk) 10:10, 10 June 2023 (UTC)

And also do you think Crh-RO needs to have own Portal? I did redirect it actually to crh. Also is it not better to use "(Romania)" instead of "[Romania]"? Zolgoyo (talk) 11:45, 10 June 2023 (UTC)

For technical reason, parentheses are restricted (at least in English) due to the way category names are determined from the English language name associated to any given language code: any opening parenthese (added for example for the precision of a script name after the language name) will be truncating the relevant category name. It was difficult to find a naming scheme that make the whole category system work for thousands of language names and variants in English (taking into account also the possiblity of aliases needing disambiguation). Basically region names are not linguistic subdivisions (unlike script differences), there should be distinctive names (but not all regional language variants havetheir own ISO 639 base code; using ISO 3166-1 region codes is a paliative, but it does not work as well as true variant codes (written before a possible script code and not after it (that's why the IAN registry contains specific language variant subtags, which solves what could not be solved by usnig generic and quite unstable ISO 3166-1 region codes, based on unstable political boundaries rather than true linguistic areas).

You've played around with various ways and mixed the resulting categories, this causes many redirects or existing redirects to no longer work as intended (sometimes double redirects thatI had to fix): Given that translations are made distinctly, the precision must be kept in category names, even if several categories share the same portal (by using a redirect from the portal name with a variant subcode to the name without this variant code).

Also avoid making languages that are distinct in their ISO 639/BCP 47 codes into variants: each one has its own base code, own portal, own categories,own terminologies, own orthographic conventions, even if there may be "See also" in their distinct portals. There must always be a way to indicate usable tool links, open/disabled status, statistics, user maps, and categories of users for each of them, we can't mix everything just because they belong to the same family and have many things in common, otherwise we would also merge German+Alemanic+Dutch+Luxembourgish, Serbian+Bosnian+Croatian, or all Turkic languages together, or all creole/pidgin languages with one of their base languages, or all Chinese languages (Mandarin+Hakka+Wu+...); and this won't help making the separation when we need them for translations, glossaries, or grammatical features or conventions.

It just works if instead we are linking by appropriate references (like "See also" sections, or some navigation banners in categories, or links present in pages listing languages by subfamilies)

Users may still want to clearly state they are spekaing a specific variant, even if they are then listed in a single portal (but in different sublists as needed). For this reason as well we can't merge all Turkic languages (even if they emerged as dialects from a common base, they have been differentiated by different contacts and borrowing, plus different cultures and religions and different scripts introduced and retired at different times in history and different places): they may progressively split, or will be absorbed into anoer major language, or will merge again after the resolution of a period of conflicts or when facilitating cross-border contacts: today many variants are no longer separated for long, they can communicate and join their efforts and even adapt to what each variant borrowed by forming back a common "hat" language, righer than what it was in their origin. Verdy p (talk) 04:10, 11 June 2023 (UTC)

Blocked

I have blocked you.

You were warned multiple times. I, and many other people here, tried to explain what is wrong about your behavior. Evidently, you either can't understand the problem, or choose to ignore the warnings and the explanations. There is no other way to stop it but to block your account. Amir E. Aharoni (talk) 08:18, 17 June 2023 (UTC)

I don't even know the reason of this, I was just using the normal review process nothing was displayed at all, not any warning or so. What do you mean there ?

What kind of behavior do you mean? There was no edit waring displayed at all, there was nothing shown in histories in the Translate UI this morning or yesterday. I did not receive any notification here too (but visibly you jsut don't want to talk, but that's not the corerct reason then as given above. Your infinite blocking is completely unjustified.

You did not send any notification for any problem I may have not seen. But even my own history of edits displays absolutely nothing visible that could explain what happened to you or could have warned you of something that I was never aware of and could not detect. Verdy p (talk) 08:20, 17 June 2023 (UTC)

@Nike: @Siebrand: @Abijeet Patro: @Jon Harald Søby: @Raymond: I appeal to this, can you check why Amire80 reacted like this? What did I do wrong and why was I never notified of anything? If there's a missing/unimplemented notification in the UI of this wiki, or missing some other infos in histories, how could I be responsible for that? Maybe the only really disruptive behavior here is Amire8'0s one, as he tends to take proprietary decisions by his own including when frequently posting his comments on user pages instead of user talk pages, and repeatedly refusing any discussion (seen many times with various other users trying to do their best). I've helped a lot of them. I've done a lot, may be someone did not agree or suggested something else, and ni almost all cases I accepted their changes and discussed otherwise.

There's nothing I can see made today that is not in full line with existing policies and limits of the current implementations (where people should then talk if something is not visible in the UI or documented). Even this morning I sent a bug report in Phabricator about one problematic message using a possibly incorrect plural syntax for negative points. Is that the cause of this blocking? Was it wrong to report it to Phabricator, using the link proviced in the UI? Is a report made in Phabricator a "bad behavior" that causes an action to be taken here instead?

I also do not see anything in Amire80's own history made since yesterday early morning (in one hebrew messages), only my blocking made this morning. And I did not edited any Hebrew message, all recent edits made by Hebrew since June at least are exactly what he made, I did not change anything and did not review it.

If this is the fact that I started editing very early this morning, I was just woken up at early morning at 04:27 CEST (local time) by a second major replica of an earthquake that occured very near my location near Niort since yesterday. Magnitude 5.8 yesterday evening starting at 18:28 CEST, with some damages to a few old buildings or a major electric infrastructure (but thanks, no deads or severe harms to people, only one person with minor harm because he fell in stairs). That earthquake heared like a huge industrial explosion or underground collapse of a cavity, possibly caused by severe lack of rain water and infiltration since about 2 years, followed by about one minute of tremors. But no damage at my home or in my immediately visible surrounding periurban area, as these tremors were mostly vertical with no significant horizontal balancing, and most buildings are not very tall on one floor and there are very few chimneys; damages occur mostly on old historic churches (there are still other smaller replicas ongoing every 2-3 hours). This has been reported on all French news medias (very exceptional at this scale in metropolitan France, notably in my region, even if small earthquakes occur frequently at magnitudes 2-3, most of them unnoticed and much shorter in time). If interested you can see official reports there (https://renass.unistra.fr/fr/zones/france/) or on Wikipedia (https://fr.wikipedia.org/wiki/S%C3%A9isme_de_2023_dans_l%27Ouest_de_la_France). Verdy p (talk) 08:30, 17 June 2023 (UTC)

No reply? the reason given above (edit waring) is just completely false, as there was none at all.

All I did was to change a single regular SPACE (U+0020) into a non-breaking space (NBSP, U+00A0) (represented as HTML-encoded character entities in both cases) in a single French message that was clearly needed for strict conformance with French rules (even if in this case, the English language used in the source message is possibly more permissive, but this is questionable) and for full coherence with other similar messages (where NBSP is also used in English!). And there was an appropriate explicit edit comment (no longer visible now, because Amire80's deleted the message in question along with all its history of edit comments, and just gave in its deletion comment an incorrect copy of what I really submitted). My edit which was respectful of rules, in a message that was available for translation (with just a documentation warning asking us to explain why changing the default English version was needed; that same message has been translated in other languages using other separators as needed in those languages), and cannot be called "bad behavior" from me. Amire80's ignored my edit comment, and acted superficially like a bot, as if this as not needed, and even if my edit did not cause any issue to anyone, not even any technical one.

Amire80 just took a decision by using silent adminsitrative privileged actions (old page deletions made in the past, leaving no history visible in the UI, that prompted no warning or notification being ever sent anywhere and at any time that could be visible in the UI); he did not seek any way to tell what he did and decided purely alone on the translation of a single message in French, a language that he does not know, and for which I made nothing wrong at all that could be seen as "disruptive" by anyone (except himself for untold reasons), or causing any technical issue. Anyone on this wiki could have been trapped in that case. I'm not guilty of anything if ever this could be possible defect of the UI, that is unable to detect his silent "proprietary" actions. Verdy p (talk) 01:47, 19 June 2023 (UTC)

To contact me

Because of Amire80's action above, I won't be able to reply anywhere on this wiki, except on this user talk page.

But now I fear this wiki will return progressively to its old buggy state it had years ago, when it was not really prepared to manage as many languages as there as now. I've documented a lot of things that was never documented, I submitted many bug requests to project maintainers, including another one a few minutes before I was blocked here (and if you look at my edit history on June 17, everything is valid, nothing has been reverted by me or anyone else (not even by Amire80), meaning that there was no "disruption" at all causing any known technical issue to any one.

But it's unlikely they will take the risk of investing time now that this wiki is a private property of Amire80 and does not follow the Wikimedia policy but is managed this way by some admin that does not say what he does and does not want to talk on this wiki, but alters even user pages by posting there long posts outside their talk page and then lies if he's questioned. He has helped much less people here since years (even before he was granted admin privileges).

Amire80 talks about my "wrong behavior" but does not want to admit his own bad behavior, not respecting any other users and their efforts. Look at what he reverts frequently in languages that he does not know and from various users (a few recent examples: https://translatewiki.net/w/i.php?title=MediaWiki:Anoneditwarning/kr&diff=next&oldid=11664837, or https://translatewiki.net/w/i.php?title=MediaWiki:Blockedtext-include-details-queries/tum&action=history, but there are many other examples in Amire80's history where he conducts real edit wars in languages he does not know at all and without discussing with anyone, and is just destructive and made silently). Amire80's behavior on this wiki (for lot of languages) is highly questionable (and for much much more frequent cases than the very few that he opposed to me, for which there were attempts to discuss with him, but his own replies were just sending absolute orders to accept without question what he did and threatening users, refusing any form of discussion).

I'm still open to questions (I can still reply only on this page). I still follow the project and will signal defects as much as I can (but not on this wiki). I have other contact pages, and I also work with other people around.

I've made my best since years, worked a lot for the community, and because of this tremendous and patient work, there may have been discussions about a few items that were discussed and where other solutiuons were possible but vould have been discussed if there was disagreement, or improvements to do. What I did since many years and with many thanks received from various project owners and other wiki users (in Wikimedia or elsewhere).

I've made most of the work that was needed since years to change this wiki and make it really internationalized and properly organized and navigatable, solving many technical issues. I just hope that this wiki will not return slowly to the limbos it had years ago, with poor or insufficient administration, poor/missing documentation, when local admins frequently did not reply to basic requests and left many quirks unsolved.

If someone asks me about something on this wiki, I can explain what could be done, but I won't be able to do things myself for now. If you don't feel confident talking here (because you fear unexpected Amire80's reaction that has already been the cause of many users abandoning work on this wiki for many languages), you can talk to me on my Wikipedia page, or using the "email" feature of this wiki. -- Verdy p (talk) 02:04, 19 June 2023 (UTC)