User talk:Verdy p/LiquidThreads

This page contains archived discussions using the Liquid Threads extension. You can still participate in existing conversations, but you should start new conversations using the new discussion tools on the main talk page.

Bonjour, je remarque qu'une nouvelle fois, vous avez modifié le message Wikimedia:Copypatrol-header-loggedin/fr avec une syntaxe qui ne fonctionne pas. CopyPatrol ne gère pas la sytaxe GENDER et le message s'affiche tel quel sans prise en compte du genre (puisque cette information n'est pas accessible en dehors de wikipédia). Pouvez-vous cesser de remodifier sans cesse ce message avec une syntaxe erronée ? Ou au moins, ayez la courtoisie de m'expliquer pourquoi vous imposez cette erreur avec autant d'insistance...

Merci d'avance.

Désolé mais je ne me souviens pas de tout, et là c'est passé sans que je vois de quel logiciel il s'agissait (et il n'y a toujours aucune note sur ce sujet quand on est dans l'éditeur (où on ne voit pas non plus les historiques, on ne peut pas se souvenir de tout parmi les dizaines de milliers de messages, dont beaucoup sont également liés par une boite "Identical" qui promeut l'unification).

Si vraiment ça te gène, qu'est-ce qui t'empêche de mettre une note dans la sous-page /qqq pour rappeler que cela ne prend pas en charge la syntaxe GENDER: de MediaWiki ? (alors que ce logiciel CopyPatrol est explicitement conçu pour agir sur les contenus des wikis basés sur MediaWiki... il n'en comprend toujours pas la syntaxe, et ça mérite d'envoyer une demande de modifs pour prendre en charge cette syntaxe aux auteurs du logiciel, car cela se produit ailleurs dans d'autres langues).

Donc merci de ne pas invoquer une prétendue malveillance, ce n'est pas volontaire et vient d'un défaut de l'interface ou des documentations affichées qui ne mentionnent aucun rappel. Et un tel oubli après plein de mois passés est parfaitement explicable.

Et là visiblement tu ne fais qu'utiliser l'interface de relecture sur des projets, pour relire les messages en masse. Tu emploies exactement la même chose que moi et admets que cette interface ne montre rien.

Concernant les groupes de message non destinés à produire une syntaxe MediaWiki, ce serait bien de demander aux développeurs de translatewiki.net de prendre en charge la détection de syntaxes MEdiaWiki non prises en charge (dont {{GENDER:}} pour l'accord avec les noms d'utilisateurs, et {{GRAMMAR:}} ou {{PLURAL:}}... afin qu'on ait au moins un avertissement: ce groupe de messages pourrait être paramétré par exemple avec une liste d'expressions régulières détectées dans le texte et qui affiche un message (ou un modèle) associé dans une bannière de l'interface.

Veux-tu que je contacte les développeurs pour proposer ce paramétrage (global au groupe de messages entier, ou spécifique pour certaines langues)?

Bonjour @Verdy p, je suis désolé pour le délai de réponse mais je ne me connecte que rarement à translatewiki et je n'avais par conséquent pas été informé de ta réponse. Je voulais tout d'abord m'excuser si mon message a pu paraitre agressif ou insultant, telle n'était pas mon intention. Ma formulation un peu sèche était due à mon incompréhension suite à plusieurs modifications identiques sur ce même message que je n'ai pas comprises.

En effet, je n'ai pas modifié ce message par hasard en utilisant les outils de relecture mais je suis intervenu sur les libellés qui me semblent incorrect dans les logiciels que j'utilise. Je suis intervenu sur le message à chaque fois que l'affichage était incorrect dans CopyPatrol. Je n'avais donc que l'historique de la page pour essayer de comprendre pourquoi ma modification était annulée régulièrement [1]. Je n'avais pas imaginé que tu n'avais pas accès à l'historique ni à l'explication que je laissais dans le résumé de chacune de mes modifications. Je pensais que tu recevais une notification lorsque je procédais à l'annulation de tes modifications avec le motif (comme c'est le cas sur Wikipédia par exemple). J'ai ajouté une phrase dans la sous-page /qqq pour informer que l'outil est hors wiki et ne gère pas la syntaxe "GENDER". Je ne connaissais pas la sous-page /qqq permettant de documenter le message, je te remercie donc pour m'avoir appris cela :) !

En ce qui concerne la gestion du GENDER dans CopyPatrol, je suis pas sûr que ce soit techniquement possible car l'information du genre est une information personnelle qui, j'imagine (RGPD?), n'est pas transmise aux outils externes.

Merci en tout cas pour ton message, même si je ne l'ai pas vu avant car il m'a été très instructif pour comprendre tes contributions et pour apprendre de nouvelles choses sur translatewiki !

En espérant que mon message nous permette de rester en bons termes, je te souhaite bonne continuation dans tes contributions :) !

hi Verdy p,

i have notice you revert my changes three times. Original string => Preparing files for transfer.... a) from Préparation des fichiers pour le transfert… to Préparation des fichiers pour le transfert... b) from Préparation des fichiers pour le transfert… to Préparation des fichiers pour le transfert... c) from Préparation des fichiers pour le transfert.... to Préparation des fichiers pour le transfert...

can i know what's wrong about my changes. on changes c it's similar to original string and you say it's grammatically wrong so i have changed it to scape character which is same as Préparation des fichiers pour le transfert... this then why you are reverting my changes. I have changed this because it's giving us lint error in our project and our project is not compiled due to this lint error we have to fixed manually every time when translate wiki PR comes.

same with Négociation de la liaison... this string.

Most probably your lint tool gives false hints.

You have attempted to use character references that are not needed, and not even used in the English source (such thing is valid only if the message is included in HTML (or MediaWiki, but even in Mediawiki there's no need to do that, except for a few ASCII characters; native UTF-8 should be used everywhere as much as possible, the only exception being when there's a specific syntaxic issue). Also compatiblity characters should be avoided. Note also that these strings are feeding the translation memory, independantly of the target projects, and as much as possible native UTF-8 is better; in addition is allows searches. Kiwix is a standalone application and does not render UI messages within an HTML page for webbrowsers (this is different from the Wiki content that will be rendered in a HTML component, separately from the UI).

I've not "reverted" anything but updated things as they came or were updated from the English source. Aslo I've never said anywhere that this was "grammatically wrong" there (with the linguistic meaning e.g. for French). but maybe syntaxically incorrect for the target encoding language (e.g. HTML assumption). I think your linter may giv e lint errors only when you use the HTML syntax of character entities when these messages are not parsed by an HTML parser. But maybe your linter rule detects that the English message uses 4 dots instead of 3 for the ellipsis (this is then an error in the English source, and thje same linter rule would also complain with your own changes trying to fix it on the incorrect place; note also that a linter should not use the same rules about punctuation across all languages: languages use punctuation marks differently, even for dots, commas, semicolons, colons, question marks, hyphens or whitespaces: look for example in Greek, Armenian, Chinese, Spanish, and so on; English punctuation rules applies to English only).

hi verdy thanks for explanation. But our lint not giving false hints. It is actual error here we should replace these string with from three periodic to four periodic or we can Replace "..." with ellipsis character (…, …). and sorry you are not telling me this is grammatically incorrect actually Eleassar said this to me.

i'm attaching some screenshot here.

I don't see any warning, just a possible replacement suggested by the text editor. However the ellipsis character in Unicode is encoded mostly for "compatiblity" with legacy encodings (and notably for use on terminals or typewriters with monospaced fonts, and this is not the case here; and the result is even worse in English where there are four dots: replacing three of them and not the fourth one would not represent an ellipis correctly: look at the message in English, dots are not even using the compatibility character; look in all other occurences, that compatiblity character is never used and never needed; and with most fonts it has the wrong weight, dots are too thin... because they were packed to fit into a half cadratin for the average width of characters in monospaced fonts, or the spacing between dots is too narrow and not correctly balanced). Anyway four dots is incorrect even in English; and in that case, where are you supposedto use the ellipsis: to replace the first three dots, the the last three? This makes no sense.

hi vardy thanks for explaining, but can you please tell me how i can avoid these warning on IDE, because until these warning in our code it can not pass on CI. I have check the other translated files also. there also TW using the ellipsis character as well, e.g https://translatewiki.net/w/i.php?title=Special:Translate&group=kiwix-android-strings&language=ast&filter=&action=translate and in many more files. in most of the file TW using … instead of ... , so can you help me in this.

I don't know which IDE or editor you use. May be it's an issue in that editor, but I don't see whay a warning ni the code editor or IDE would block anything on your dev project (which should not depend on the text editor or IDE you use for specific platforms that are not the same as the target platform (e.g. if you edit on Linux the app intended for Android; you could as welle edit it on Windows, or with other IDEs). The build process is independant of your editor.

And this is not blocking any VCS tool I know (CVS, SVN, Git, Mercurial,...), or any build process or compiler. In all cases the Unicode encoding is correct here (it may just be incorrect due to an internal transform in the editor, that can then not save a valid Unicode form).

The only cause I see is that there were four dots, and this editor is unable to choose or by pass the choice for its own suggestions (possibly conflicting between the two alternatives and then breaking the UTF-8 encoding with the wrong number of bytes expected). This looks most probably like a bug in your IDE version (apparently running in Ubuntu according to your snapshot). If the Ubuntu app is running the native app, you may try the version from Sanps or from Flatpak (they are generally more up to date with mroe revent versions, with additional fixes). Your "Jetbrains Studio" IDE is very uncommon for opensource development (due to its licensing). Most opensourced projects using IDEs on Linux use other free IDEs which have good support in cluding in their free version (MS VisualStudio Code is now common on Linux, and fully supported by Ubuntu itself, but Eclipse is supported since much longer time for Java/Android developement; IDEA/IntelliJ-based tools is recommanded only for their paid professional versions). If you use the free version of Jetbrain tools it may have limitations (I've never tried that version) and bugs some that may be very long to get fixed. And mya be this is not the editor itself, but other plugins you've installed on it, or missing devependencies or an incorrect environment in your installation (check your user locale, is it using "en.UTF-8" or just the default "en"? Have you installed the full linguistic support for your Linux host, including encoding coversion tools and libs?).

Have you tried to remove the extra dot in English, given that it's undesired?

As well, given these are "Lint warnings" in the generated report, which Lint tool does your build use? May be you've incorrectly setup the rules to use a too strict or incorrect mode (e.g. for targetting terminal applications for the console to be rendered with monospaced fonts, where in fact these are strings for a graphical UI that should not use monospaced fonts). Linters normally have configurable options: you may needto enable/disable some of them according to your real target (be careful with default sets of options). I have no idea how you generate these "reports" in your build process, and why these are "warnings" (normally non-blocking) but your build project is set up apparently to block on ALL warnings, even if they just give possible hints (applicable only to some project targets). Clearly the Android UI does not need these to be "fixed". Ellipsis characters are clearly encodingf in Unicode for compatiblity with terminal apps or old typewriters, or when in fact the target rendering will not be based on Unicode but converted to legacy 8-bit charsets.

Also according to the online docs of IntelliJ IDEA, the Linter offers you options to shut up these warnings: if you click on one of them, it should propose you several choices for each warning but there are also general options you can set on any file or group of files, e.g. with the Shift+F6 shortcut, or by clicking an icon in the message). That tool has really a lot of Linter rules because it targets many application types and environments, some of them having unusual compatiblity requirements (including obsolete ones): all Linter tools I've used on all projects need to have specific Lint messages shut off, i.e. either silently discarded or configured to use a lower severity level (if IntellIJ IEA supports it, you may need to cahnge that rule to send a "Info" severity instead of the "Warning" severity, if your build projects is configured to block even at the "warning" severity level, as if they were errors (such setting in build projects is very unusual, most opensourced projects won't compile without warnings to be emitted, for later analysis and possible fix, but not to block the construction). It's then normal that you get a "build report", but if the report onily contains such warnings and the build was completed, your build is in fact successful.

https://translatewiki.net/w/i.php?title=MediaWiki%3AWm-license-self-multiple-licenses-with-author%2Ffr&diff=next&oldid=11448025&diffmode=source

Pourquoi préférer « sur », qui me semble boiteux et est peu utilisé (deux pages sur Google Livres pour "détenteur des droits d'auteur sur" comparé à 10+ pages pour "Détenteur des droits d'auteur de") ?

On détient des droits de faire quelque chose (l'action), mais bien sur quelque chose (ce sur quoi porte l'action elle-même, l'œuvre, un objet indirect). En l'occurrence en terminologie légale c'est bien des droits sur les œuvres et non des droits des œuvres. C'est vérifié dans les dictionnaires et divers ouvrages juridiques. Il n'y a rien de bancale du tout, les prépositions ont un sens différent et l'emploi de "de" est inapproprié même si on l'entends souvent à tord (notamment pour des non-juristes qui ne font pas bien la distinction des objets). Et c'est encore plus vrai si on inclue en plus l'objet du détenteur des droits (celui ou ceux qui autorise les actions, ici l'auteur en tant qu'entité générique qui peut désigner une personne ou un groupe de personnes qui peuvent dispenser ces autorisations).

Bref on ne détient pas les droits d'une œuvre, on détient des droits (d'auteur ou moraux) sur une œuvre. L'usage de la même préposition "de" pour tout (auteur, action et œuvre) prête à confusion.

Même en cherchant sur Google, on a clairement cette définition (appuyée par plein de sources juridiques) : "Le droit d'auteur est le droit de propriété intellectuelle dont tout auteur dispose sur ses œuvres. Il permet à l'auteur d'une œuvre de décider de la manière dont son œuvre peut être diffusée ou utilisée, et de percevoir une rémunération en contrepartie de l'exploitation de cette œuvre.", ou encore "Quels sont les droits de l'auteur sur son œuvre ?", "Quelle est la limite des droits d'un auteur sur ses œuvres ?", "Qu'est-ce que le droit moral sur une œuvre ?", et des sources officielles comme "https://www.culture.gouv.fr/Media/Thematiques/Propriete-litteraire-et-artistique/Conseil-superieur-de-la-propriete-litteraire-et-artistique/Files/Fiches-techniques-PLA/Fiche-internet-4-droits-conferes-par-le-droit-d-auteur2", et des tas de fiches de la SACD ou de documents l'OMPI (WIPO) en français.

D'autant plus qu'en France on a divers types de droits (on n'en n'a pas autant avec le copyright en droit anglosaxon, même si depuis ils ont ajouté des droits dits "voisins", et reconnu aussi le droit des brevets, le droit des marques et le droit de personnalité, le droit ad hoc des bases de données...). On doit distinguer ce sur quoi' porte ces droits (l'œuvre elle-même, soit en tant que propriété intellectuelle, soit en tant que support physique de l'original ou de ses copies), de qui les possède et peut en disposer, et la nature des droits d'action qui peuvent être concédés pour un usage précis (mais pas les droits moraux exclusifs incessibles et inaliénables de l'auteur, dont son droit d'image, indépendants du support utilisé, mais non reconnus en droit anglosaxon, sauf par accord international dans les pays d'origine où ce droit existe).

LiquidThreads deprecated. We are told to archive them to use DiscussionTools with standard MediaWiki, but the archival by *moving* their threads to another subpage is still not possible, even in their own user talk pages (only a few admins can do that). The same is true for any archiving system based on pure Mediawiki pages (as long as they cannot be renamed like in all Wikimedia wikis).

There's a good point for limiting page moves in this wiki, but not on their user pages and user talk pages (as long as this preserves the base page name and the namespace, moving any content across subpages of the same page base should be free, and as well renaming subpages when needed, letting users and maintainers of other project pages managing their archives conveniently and locally).

Hi.

I warned you many, many times not to translate into languages you don't know.

This edit was completely wrong. You already made it in the past, I reverted it, I explained to you that it's wrong, and I told you that I'll block you if you translate into languages you don't know again.

I guess you don't understand warnings.

This time it's for a week. Next time it will be permanent.

Pourquoi avoir annulé ? Pas de justification en plus. Alors ?

Parce que tes 2 justifications de modif sont toutes les deux complètement fausses. Il n'y avait AUCUN symbole degré, c'était bel et bien un o (et aussi tu as mis ensuite un code HTML inutile, il y a un caractère Unicode dédié pour le o en exposant en finale des abréviations latino-romanes), et parce que l'abréviation commune est bel et bien "Appt" dans les ressources postales de référence en France, Belgique, Canada et de nombreux dictionnaires, certainement pas "App." qui n'a strictement rien de commun et que tu as inventée sans vérifier ! La seule chose à corriger était le point inutile après la finale de "Appt", que j'ai viré ensuite.

Merci pour les explications. Ç'aurait été génial de les voir dans le résumé.

Oui mais je m'en suis rendu compte APRES coup que cela venait d'une modif de quelqu'un d'autre après les miennes, j'ai d'abord vu une mise à jour de la source (j'étais passé par l'éditeur wiki, via la version anglaise listée comme mise à jour, et non l'interface de traduction, j'ai vant tout pensé quel quelqu'un ne respectait pas les conventions et ajoutait du HTML là où ce n'était pas nécessaire). De ton côté tu aurais pu voir que tex commentaires étaient faux, car tu n'as pas vérifié (un simple CTRL+F dans le navigateur pour chercher un degré ou une lettre o aurait montré que c'était correct, de même tu n'as pas vérifié ta supposition que "App." était une abréviation commune, ce qu'elle n'a jamais été et que tu as juste supposée, donc ton commentaire qui l'affirmait était faux).

Pourtant, Ctrl-F avec « no » ne mène pas à « nº ». Quant à « App. », c'est une abréviation acceptée pour appartement.

« tu as inventée sans vérifier ! […] de même tu n'as pas vérifié ta supposition que "App." était une abréviation commune, ce qu'elle n'a jamais été et que tu as juste supposée »

Une simple recherche sur le site de l'Office québécois de la langue française t'aurait montré que c'est en effet l'abréviation usuelle au Québec (confirmé dans d'autres dictionnaires québécois comme Usito et le Multidictionnaire de la langue française) là où Cantons-de-l'Est est originaire.

Sinon en effet, « appt. » est l'abréviation commune en France pour « appartement », cf. Dictionnaire Cordial et Larousse.

Hi Verdi p,

Regarding your changes to the group description messages in portuguese, as, for example, this edit of Translations:Group_descriptions/mediawikiapi/pt:

1) Not repeating the word "message" at the start of the group descriptions was a deliberate translation choice to avoid the word repetition in portuguese «grupo de mensagens que contém mensagens». This applies to all group description messages.

2) In the case of the specific edit that I linked above, the translation of the name "Action API" as "API operacional" in an intentional translation choice. "API operacional" was adopted in other MediaWiki messages and in other documentation of MediaWiki in portuguese, which you didn't update. So now there's an inconsistency. Besides, the translation has been standardised for ages in the portuguese translation guide, at Portal:Pt/Cheatsheet/pt#action_API. Why would you change it in this message, in portuguese, to "API Action"?

Regards

Have a look at https://translatewiki.net/w/i.php?title=Group_descriptions/pt and see how you can make it coherent.

What's the use of pages like Category:Intro/he, Category:Intro/cy, etc.?

It may be useful when there are several pages for that language, but when there is just one, as it is for almost all languages, it's useless. The whole point of a category is that it's for a group of things, not for one thing.

If anyone ever wants to create a category for intro pages, they can do it. Pre-creating them only makes lists of pages unnecessarily longer.

This makes those pages accessibles by the parent category for each language. Thye are reproducing the same categorization as pages in English. And thye follow the same logic that instructs since ever to categorise all translated pages (and their categories) by language. Even if they still contain only one page per language, this can change when there are more translated pages added). Those categories have existed since ever in English and their content in other languages also grows slowly.

They are not "pre-created" but created on demand, each time there's one page or subcategory referencing them.

And I absolutely don't see where "this makes lists of pages unnecessarily longer"; in fact that's the reverse, this makes them shorter by not mixing languages. There's no overpopulated categories, and otherwise there's no explicit "list" of pages to maintain, so I don't see what's your point. Everything reamins simple and you see a single simplified structure in English and the rest can come at anytime and ermain navigatable using the same scheme. I don't se why you'd like to remove these tyo make is site less navigatable for non-English languages, and have these translated page left unreferenced, unused, non seen by their intended audience. There's not a lot of these categories anyway for each language, they "close the gap".

Also you're not alone on the site. Those categoies have a long history and you may want to look at histories for English

Those categories don't have a long history. Most of them have one revision created by you. I wasn't asking about English, but about other languages.

Most of them aren't even translated, and translation wouldn't be very necessary either. It's just a category.

So I'm asking again: how are they useful? If by "parent category", you mean categories like Category:Localisation/ab or Category:Localisation/he, then that category is not useful either. There are no links to it from anywhere (except maybe the same category in other languages), and it doesn't include any useful pages.

Is there anyone who actually uses it for navigation or finding content? As far as I can see, those are just nearly-identical manually-created pages that include no content and serve no purpose. It makes sense to create categories when they serve a purpose for navigation, but most of these do nothing.

They are creating since ever according to the statement that is no the main category and all instructions, to not mix languages and categorize each langauge specifically. Yes they were essentialyl created by me, but because they were requested. And they have allowed the English categories to remain maintainable and all other *existing* translated pages to remain accessible and navigatable. Naturally, there are less translated pages then English pages, but their flow ghrows slowly over tyime and they can remain in sync with Engmish pages. The same thing is used in other multilingual wikis, so this is not new (and without it, the wiki was nearly unmaintainable and really difficult to navigate and maintain in *all* languages (including in English). And everyone can see what can be translated and what is missing. They are also crated each time there's a listed missing category. Their size is extremely small, they are used via search tools as well and allow more people discovering pages that *are* translated, and that *may* also need updates. Now translators can wok on translating pages that they want or are interested in. This wiki has always had the purpose of being multilingual and open to many languages (focusing it to English only would have been a serious defect, as a way to show that only English needs to be maintained, and thus that even this entire wiki would not be needed at all, Mediawiki itself would be for English speakers only; that's clearly not what the WMF wants and promotes since long, minorities have thei place and we must facilitate their integration and not exclude them). May be you don't care because you natively use two major languages and can use English as well without much problem. But your point of view here is clearly not as open as what the WMF promotes and wants. We are not here to speak only between technicians using English for everything, as if it was a requiremetn for all Wikimedia-supported projects. I respect minorities, but visibly you don't care about them and are not ready to give them a place for their voices.

You say that you created them because they were requested. Who requested them? Specifically, who requested the creation of Category:Intro/he? And who requested the creation of Category:Intro/dv?

You also say that their flow grows slowly over time. How many of the Category:Intro/* pages actually grew after you created them?

They are created when pages are listed in them. There's a tracking category for that. The verbal request with instructions is in the main category of the site since its origin in February 2009 (even before you joined this site) by Siebrand, with a small modification by Kaganer a short time after to make this even more explicit. So this is not new and its originating from the origin of this site!

Note: I wrote "on demand", not "on request" (there's no new request posted in some talk page, the demand comes from usage on translated pages). There's not been any change of rules.

During many years, managing categories was left administered, and they started proliferating and being unorganized or named inconsitantly. Slowly they were reintegrated. Now the iste only has 1 uncategorized category, the main cateogy in English. All pages are navigatable by categories. And when you say they are not referenced, you're wrong. All pages have at least one category. Their number does not explode, but they are all organized by language as instructed, Categories don't need to have lot of members, just to be consistant. They'll populate slowly as soon as some translated page needs one of them.

I've deleted the versions of Template:Translators editintro in Ukrainian and Russian, which you've created. They are machine translations, and they had multiple mistakes.

Unedited machine translations are vandalism. They are worse than no translation at all. You received multiple warnings about this, and now it's the very last one: If you publish a machine translation with mistakes into any language after it, you'll be immediately blocked.

These were not "unedited", and not machine-generated, I included some grammatical and technical-syntaxic fixes to make it work as expected; it "vandalized" absolutely nothing; you may prefer something else and fix it, without changing anything in the navigation. That's how wikis are done everywhere. You chose the lazy way by just deleting, which is quite aggressive and in fact just destructive and it helps nobody. I used much care about doing that, and checked identical parts used on other Russian and Ukrainian wikis.

I don't know why you want to be so aggressive about that, given that you are also doing your own mistakes (sometimes not corrected after years and corrected by other people: this is not dramatic, but apply your judgement to your own edits and be fair: everyone on this wiki commits some minor errors that are not seen immediately and fixed later by others). But visibly you don't want to correct anything, you want perfection at the first time (but even you, you can't be perfect all the time, and views on translations may change, with better suggestions, or because a terminologic conflict appears and needs to be resolved to avoid new ambiguities; as well you have blocked mutliple changes by reverting them even when evidences were presented to you; I doubt your real desire to cooperate and that you think that you just want others to follow your orders or point of view, by sending threats like this one against them, which are compeltely unjustified. In french we call that "throwing the baby with the water of the bath" (litteral translation, the real expression is idiomatic in French and may have other similar but different translations in other languages) when you don't respect those that make much of the work since very long, including for basic maintenance that you neglected a lot). The site would not be so much usable for translators if I had not maintained that to make it navigatable in all languages for all (including for you), and allowing them to see everything that needs not jsut translation but also review. This site works like that: translating is not enough, others will also review everything (not delete, but fix what appears to be needed): translation is always a best effort.

Why was it edited: there was a change in the source to show some additional basic syntaxic help (and several translations of that header also were missing that info, or used incorrect links). And a link to the doc page for the User template was added (but it is not translated) explaining the role of interwiki prefixes. This change was needed dur to the fact that various users did not use the expected format in translator lists (because the header shown was probably not clear enough for them): my intent was to clarify that in all existing languages (at least the syntax for common cases, and its meaning).

Please stop arguing. Russian is my native language. They were wrong, period. If you don't understand that this is vandalism, you are in the wrong place.

Why don't you just fix it?

Because other people are not supposed to fix your inherently wrong texts.

So people are not supposed to review anything here? We all make errors, including you. Fixing them is all the job, it takes time, and patience. We are supposed to work in community here and help each other, and everyone makes the best he can to improve the situation, but never definitely because someone else will have a better idea, or things were not so obvious as the first thought they were.

This edit was unnecessary and disruptive.

Editing a thread title almost a month after it was posted and resolved unnecessarily bumps it to the top of the page and sends emails to people who follow it. This causes much more waste of time than an all-caps title, which would have just quietly gone away after a few more days.

I had already asked that you stop doing this at least once: Thread:User_talk:Verdy_p/Editing_old_messages_on_Support.

That's not so old (this was not in the Limbo and still visible on the 1st page), and there was a remark about that (notably to you, but also to the initial submitter and to possible other readers). That additional remark would have moved the thread up anyway, but I don't know why it is disruptive to continue a talk with a small remark which also reminds that why we should not capitalize everything.

You wouldn't have to make this remark if you hadn't changed the title, and you shouldn't have changed the title. Just stop doing such things.

You've already done that yourself in the past. Usually this is not needed, but keeping them gives a bad example to others.

In most wikimedia projects this is clearly prohibited and changed promptly (sometimes more radically, this causes the entire message to be removed (this is part of their policy). Many social networks or forums also don't allow that as well and their moderators are managing this usnig eother ways.

Most people don't like "ALLCAPS" style because they are in fact slower to read, they are tolerated on isolated words when there's no other way to emphasize that word or if these are abbreviations and there's a need to distinguish them from regular words. But others now use other ways to emphasize their message in social networks: they use many colorful emojis, often needless as they mean almost nothing clear, and makes navigating page more difficult to follow. Emojis are not tolerated everywhere (and in subject lines of emails they are old tricks used mostly by spammers, and more rarely by advertizers that use them very sparingly as they cause accessibility problems, recipients are more likely to delete these messages without reading anything). You already know that, but should be aware that if you accept that, others will follow and it will become "the" standard.

Where have I done it in the past?

Salut ! Est-ce que je peux traduire les noms de langue dans les modèles Template:Languagename/* en sicilien et italien ou c'est juste limité à l'anglais/français ?

Non ce n'est pas limité, tu peux ajouter. Ceci dit, languagename/db contient de très nombreuses langues et le but a été de compléter leur noms pour vers des langues les plus connues ou utilisées conjointement en tant que langue (par exemple le nom finnois du suédois). Au minimum il traduit vers la langue elle-même, vers l'anglais et le français (références ISO).

Si tu regardes bien, il y a déjà d'autres langues dispersées (pour certaines paires les plus courantes). Et partout autant que possible, il y a déjà les autonomynes (de la langue vers elle-même).

Tu peux donner un exemple ici de ce que tu veux mettre, je te dirai si ça marche et tu pourras faire le reste de la même façon si tu as envie. Attention: l'indentation est réduite au minimum, ce modèle doit rester maintenable (sinon l'envisage de créer des languagename/db multiples, un par de langue cible ou de rempli, ce qui évitera des effets de bords pour d'autres traductions de sorte que l'anglais, le français, restent stables, comme ce qui est fait pour les noms d'écritures et que cela n'induise pas trop de coût dans le serveur du fait des pages en cache à régénérer).

Note aussi que ce modèle vient là en complément de ce qui n'est pas traduit dans CLDR (qui référence beaucoup moins de langues) et dans l'ISO 639 (qui ne contient que des noms anglais), les deux ayant des évolutions très lentes (pas plus d'une par an, plus des mois encore pour prendre en compte les changements et les voir publiés dans CLDR): il évite de n'afficher que le code langue en tant que dernier repli, faute de noms.

Bon, ce modèle peut servir pour le sicilien où rien n'est traduit sur CLDR (et je n'arrive pas à traduire là-bas, vu que le Survey Tool a un bug). Un exemple de traduction est "finiciu" pour phn.

Oui le CLDR Survey est très lourd, très lent quand il est en opération, prend énormément de mémoire dans le navigateur (au point de le faire planter facilement), et pas ouvert en permanence. En gros, il avance surtout parce que les plus gros contributeurs utilisent autre chose, l'édition "en masse" en soumettant des fichiers complets qui sont ensuite intégrés mais passés en revue seulement pendant 2 ou 3 semaines, avec l'interface sur Survey, très lente, et qui ne parvient pas à enregistrer les votes de tout le monde. De fait, à chaque tour (en gros 2 saisons par an), seule une partie parvient à passer le seuil de validation et le reste n'est pas publié et il faut encore attendre des mois le scrutin suivant (pour certaines données on doit les réapprouver plusieurs fois, si on y arrive).

Au final, la progression est très très lente et le plus gros des mises à jour de CLDR vient de quelques contributeurs "privilégiés" (en gros venant des GAFA qui ont des comptes spéciaux leur petmettant aussi des votes en masse et avecv un poids plus élevé que tous les autres: s'ils se trompent, c'est long de leur faire changer d'avis et il faut beaucoup argumenter par courriel via les mailing lists ou par des courriels directs).

CLDR n'est donc pas parfait, il est économiquement orienté par les intérêts économiques des membres du CLDR (où l'adhésion est chère pour avoir un droit de vote suffisant, mais où il manque aussi une administration assez efficace et suffisante pour suivre les demandes: en dépit du prix d'adhésion demandé, le projet manque de moyens financiers et dépend aussi énormément du bon vouloir de ceux qui lui fournissent des moyens techniques, dont les serveurs mais aussi le développement qui malheureusement n'est pas assez ouvert).

On fait avec, même si certains membres de la communauté libre sont présents (mais ils ne peuvent fournir la plateforme technique et ont un poids relativement faible dans les décisions). CLDR est un beau projet mais qui manque un peu d'envergure et d'audace pour faire tout ce qu'il pourrait faire. De fait, les meilleures sources compélmentaires restent aujourd'hui Wikidata (et les articles Wikpédia liés qui citent les références), mais où là encore beaucoup trop de choses ne se documentent qu'en anglais: il y a un biais certain dans le traitement des langues (et même la Fondation Wikimedia en convient en tentant de lancer un projet pour une meilleure prise en charge des langues régionales ou minoritaires, mais aussi des langues officielles et majoritaires des pays les plus pauvres, où on manque d'acteurs locaux.

Bref les initiatives séparées sont toujours bienvenues : tout ce qu'on peut ici, ou sur Wikipédia ou Wikidata est important, de même les portails de langues ici ne sont pas tant là pour documenter les données mais comme moyen de prise de contacts en fournissant le moyen pour les intéressés de travailler à faire avancer les choses, et peut-être parvenir aussi à intéresser et impliquer plus de contributeurs capables de travailler dans ces langues minoritaires (où la connaissance technique de base nécessaire est aussi peu disponible : il faut les aider au moins sur la partie technique et fournir des éléments de base, quitte à ce qu'ensuite ils prennent les mains dessus et décident de changer sereinement, une fois leur poids acquis et pouvant finalement emporter ou contredire les décisions prises dans de plus hauts comités qui jusqu'à présent n'ont pas trouvé d'intérêt à consacrer plus de ressources à ce projet de base).

Je ne critique pas les données de CLDR, s'il avance trop peu à notre goût, CLDR a aussi intérêt à voir se développer des efforts indépendants (qui ne seront pas "parfaits" non plus mais auront moins de biais et prendront en compte plus de diversité : quoi de plus diversifié et changeant que les langues humaines, difficiles à encadrer dans des standards techniques qui ne les suivent pas vraiment?).

Donc oui, la base est qu'au moins chaque langue puisse se désigner elle-même, et lever les ambiguités/homonymies nombreuses (certaines venant justement d'erreurs commises par des non locuteurs, les plus nombreuses étant justement en anglais et en français). C'est pour ça qu'il est important aussi de documenter les noms alternatifs permettant de retrouver les classifications (sachant aussi que les classifications établies sont aussi pas entièrement établies, faute d'assez de recherches financées et publiées, beaucoup étant aussi trop anciennes). Ces efforts indépendants (et qui ne visent pas à une uniformité par des standards trop durs) existent : Glottolog, Linguist List, Wikipedia, Commons, Wikidata, du fait que leurs listes de références ne sont pas fermées et qu'ensembles ils proposent aussi des espaces d'échanges et se référencent mutuellement). Ici aussi ce site s'est joint à l'effort (mais séparément de Wikimedia, car il y a d'autres projets soutenus, y compris pour des usages à but commercial ou non "éducatifs" comme les jeux et d'autres logiciels encore non utilisés ou peu utilisés par Wikimedia: on n'est pas limité ici seulement à traduire et adapter MediaWiki).

Mieux on organisera les choses ici (autant qu'on peut), plus ce site sera utile et aidera à faire converger plus rapidement les efforts pris aussi dans d'autres projets comme CLDR et même les normes ISO ou les standards techniques des RFCs/BCP ou du W3, qui ne sont là normalement que pour recadrer et éviter les non-interopérabilités malgré la prise en compte de la diversité et soutenir une base "minimale" commune (et ne peuvent pas prétendre à l'exhaustivité: tout ne sera jamais couvert par ces standards et normes, moins que ce à quoi on peut attendre et toujours avec beaucoup de retard et souvent une lourdeur importante pris par les décisions passées, notamment en linguistique). Mais ce qu'on fait ici doit aussi savoir évoluer et ne pas s'enfermer non plus.

On fait donc tous ce qu'on peut, mais pas avec les mêmes moyens et pas avec la même agilité, mais les deux approches (normative et communautaire) ne sont pas concurrentes elles sont complémentaires et nécessaires l'une à l'autre.

Hi,

Please don't create messages in MediaWiki space that don't belong to any group, as you did in MediaWiki:Bw-portal-check-wikimedia-localisation/en.

If you want to add such a thing, request it on Support.

Hello, I did make some requests in Phabricator, can you help me about that?

https://phabricator.wikimedia.org/T322943

https://phabricator.wikimedia.org/T322821

I have no developer privileges. But your request is ongoing at Wikimedia. And this time, the decision does notdepend only on a single local administrator of TWN, so he will have to hear the opinions of other Wikimedia users and developers, because your request here failed since months, and Amir just blocks everything here. Amir will then have to accept a more collective review and decision if they accept your request. You had a good idea to submit the request to Wikimedia Phabricator.

Please stop adding unnecessary complicated wikitext to MW high prio links. It's just a list. It is supposed to be easy to change. Adding more wikitext formatting to it makes it hard. No one complained about it.

I don't know what you think is complicate: it makes the list mich more usable, notably because you post it multiple times directly to user pages of users that get massively polluted with a very boring list instead of what they would like to present for themselves.

These long vertical lists make their user page almost unusable for something else. I just made two list titles to clarify the two sublists and then just organized these two lists into autoscaled columns. Now when you post these lists multiple times, they are correctly identifying the language for which you posted it.

And the addition was very minimimalist: two embedded templates for columns, bold subtitles for each list, and clear indication of the language code.

What is "complicate?", shouldn't you care about what users will see on their user page and allow these links to be more read and interpreted for easier use? I've not removed any item it is presentational. And still easy to change (these are still standard bulletted lists, their individual items are identical, the list order is not changed at all). And users won't edit these lists themselves (only you, but at the same time you'll change all users pages using the template by adding visible contents to them).

And why do you post that in user pages themselves and not in a thread of their talk page? After all, it is you that is sending them a message. And users would be able to read it and dismiss it, or read it later, while selecting what will interest them in their user page (and annotate items themselves as they want, something impossible with your pseudo-template that can change at any time many user pages) And now that you continue adding items to these lists, this is becoming a problem for many user pages that you have invaded massively (and with a very poor layout). As a consequence, I've seen various users dropping your post that you placed on their page (as if you were forbidding users to make their own content there about themselves). I don't believe this can be useful with the form you use.

You did it again.

Stop.

It works as it is. No one asked to "fix" this.

Oh I forgot it. but no one asked you to post such giant list on their user page, with contents that interests you and you choose, ratrher than those than interest the users. Can't you save space ? Why do you post that on their user page rather than their talk page?

They do ask, and I know what is it good for. Don't try to fix things that work well. You are only making them unnecessarily complex.

There was no complexity at all in what I did, your list was exactly as it was, and I even simplified and streamlined the includeonly/noinclude; adding only 2 short lines of codes to surround the list

Bonjour,

Je souhaiterais modifier MediaWiki:Visualeditor-ca-createsource/fr pour faire passer "Créer le wikicode" en "Créer en wikicode", ou par autres choses si on trouve mieux mais j'ai pas trop d'idée. J'ai pas les droits pour modifier ici. J'ai aucune modif à mon compteur. Est ce que tu pourrais le faire ?

Dans le même ordre d'idée, il faudrait dans l'idéal modifier le bouton "modifier le code" en "modifier en code" (mais je trouve pas la page qui est lié à cette traduction) et puis je suis moins sur du caractère consensuelle de cette deuxième proposition.

Je ne vois pas du tout à quel titre on doit changer l'article "le" en préposition "en". On a partout ailleurs "Ajouter un/une", "Créer le/la", "Modifier le/la", "Supprimer le/la", "Réviser le/la", "Approuver le/la", "Annuler le/la", etc. pour tous les noms communs désignant un type d'objet. Ici c'est un type d'objet comme un autre ("page", "portail", "modèle", "catégorie", "fichier", "image", "icône", "message", "tableau", "texte", "liste", "version", "module", etc.) le wikicode n'est pas une "langue". On ne parle ou n'écrit pas "en" wikicode", on écrit "du" wikicode de la même façon qu'on écrit "du" code (l'article "le" est bien présent même s'il est contracté dans "du" à la place de "de le").

Je ne vois pas l'intérêt de ta demande, et ça toucherait pas mal d'autres pages et sujets et à moins d'en décider sur une discussion communautaire, il n'y a aucune initiative à changer ça.

Bah si le wikicode, c'est un langage, comme le html (qui est un langage), dont il est dérivé avec des signes et des termes propres.

Mais surtout quand je créé une page de discussion, je ne "Créer le wikicode", le terme ne correspond pas à l'action. "Créé le code", ça signifie concevoir ce code, ce qui n'est pas le cas. Par ailleurs "Créer du wikicode" serait mieux, ça serait moins bien que la proposition de base, mais ça serait moins pire que l'existant. Bon de toute manière, je vais pas insister, on garde le truc qui n'a aucun sens. Tant pis.

Oui mais là tu interprètes. sinon en anglais le message aurait été "Create as source" et non "Create source". Note que le mot "source" traduit initialement tel quel en français a dans un premier temps été changé en "wikitexte" à cause de la polysémie avec les références et auteurs ou origines (suite à une décision collective en français), puis unifié en "wikicode" (là aussi par décision d'homogénéisation). Mais l'article "le" est présent depuis 2013. L'anglais l'a pas été changé non plus pour utiliser "as".

L'anglais, c'est l'anglais, j'ai pas un niveau en anglais suffisamment pour disserter dessus. Tout ce que je sais c'est que "Créer le wikicode", ça ne correspond pas à l'action, et c'est vraiment pas français. Ca existe depuis 9 ans, je peux que m'en désolé, mais c'est pas un bon argument. Bon visiblement c'est bien parti pour que dans 9 ans, ça sera toujours comme ça, je me fais pas trop d'illusion.

je ne vois pas ce qui n'est pas français. Bien au contraire le mot "créer" appelle un complet d'objet direct, et pas juste un complément circonstanciel (si on met un tel complément circonstanciel il y a un objet direct au moins sous-entendu. Alors on "crée la page en wikicode" ou sinon on "crée le wikicode" puisqu'il faut l'objet direct. Au final la forme est celle en court de modification: rien n'est créé lors de la modification, la création a lieu lors de l'enregistrement d'une nouvelle page, mais l'action pour mener à l'éditeur est "Ajouter une page" (son inverse étant "supprimer une/la page" qui ne demande pas de modification et se fiche de la forme).

Si c'est un bouton ou un lien qui change la présentation pendant la modification, cela ne "crée" rien, on change le mode d'affichage, on règle l'éditeur pour "passer au mode wikicode" ou "passer au mode visuel" et il n'y a toujours rien de "créé" en cliquant l'un ou l'autre !

En vrai le mieux ça serait même "Créer (wikicode)" et "Modifier (wikicode)", car l'action est centrée sur le fait de Créer et le terme wikicode intervient juste pour différencier ce bouton de l'autre bouton "Créer" et "Modifier". Mais c'est un changement encore plus grand (parce c'est pas habituellement de même des parenthèses) et ça sera pas fait...

Hello, there is a Latin alphabet used by the Nogay Tatars in Dobruja which is also official by UDTTMR (Democratic Union of Tatar Turkish Muslims of Romania). There are also books printed with this alphabet. There are using it also in Social Media, Website, YouTube etc. Here are some links:

Website: http://uniuneatatara.ro/en/

Instagram: https://www.instagram.com/udttmruniuneatatara/

Facebook: https://www.facebook.com/udttmroficial/?_se_imp=2JlALzFIx93azMr2F

YouTube: https://www.youtube.com/c/UDTTMRUniuneaT%C4%83tar%C4%83

Here is the alphabet showing and explaining by a woman (Noğayşa/Tatarşa): https://www.youtube.com/watch?v=I9lCsBdQBTs

You can also contact with them, you need to look it in the Website there are some possibilities.

It seems to use another variant based on the Romanian alphabet, with breve signs over vowels, dotted i (typical of Turkic languages), and comma below some consonnants (instead of cedillas, typical of Romanian orthography).

Here is the alphabet shown: https://www.facebook.com/photo/?fbid=1795600770673670&set=ma-_-_-me-_-_-%C5%9Fa-_-_-ta-_-_-qirimtatartiliuyrenemiztatarlar-tatars-%D1%82%D0%B0%D1%82%D0%B0%D1%80%D0%BB%D0%B0%D1%80-tata

Here is saying that there was a print problem and the letter ğ is written as ǧ: https://www.facebook.com/photo.php/?fbid=1793764244190656

This can also explain that the substitution of the cedilla (used in Turkish) by the comma below (used in Romanian). So Nogay writers in Romania have adapted to what they commonly find in Romania. May be Nogay writers living in Turkey use the other way (with cedillas). Breves are used in Cyrillic (in Crimean Tatar). All this confirms that Amir has made a false assumption confusing Nogay with Crimean Tatar, that he may have seen and known where he lives in Russia (near Moscow, where there may also be Crimean Tatars living there and their language is taught in Russian schools or universities).

Hello, can I beg you to discuss this problem with him and show that this is a confusing? Because this is more than 6 months ago and we just need to end this thing. He can also help for us, he can discuss with us the latin alphabet. We have many sources about using of latin alphabet. Even when he wants we can use the dobrujan latin alphabet for/because better sources of UDTTMR.

I can't do anything with him. Only aniother site admin can do something, such as Nike, but Nike trusts him for many things (but he could still order take over his decision, if there was more people other than just you and me to support this unblocking. You found some people in Romania, may be you can contact them and ask for their support (they may register here, or create their own paper signed by their university department, stating clearly that the language has official support in Romania and has developed an approved orthography

You may may also try to find contacts in Turkey, but may be they have developed a slightly similar orthography, that accepts a few other Latin variants that are easier for them to type, such as the dotted/undotted i distinction in Turkey, vs. the distinction by soft-dotted i and i with caron in Romania (or i with breve, if mimic'ing the cyrillic i with breve probably used in Bulgaria and Ukraine, and certainly used for Crimean Tatar in Russia).

You need a clear statement that Nogay is NOT the same language as Crimean Tatar (which a few years ago was still written using Ukrainian conventions in Crimea, before the Russian annexion) as it has been separated since long: Nogay speakers went into contacts in Romania and Bulgaria with Turkish and Greek people along the western coasts of the Black Sea (most Greeks however relocated from Turkey to Greece when Greece became indendant of the Ottoman Empire which was also occupying the region; Romania and Bulgaria gained their independant later but have kept stronger links with Turkey, so Nogay and Greek people could have stayed there, including within Ukraine while it was part of the former USSR), and have also modified significantly the language without influence from the Russian language, and have probably restored old ties with Turkish.

But the main problem with that Nogay language is highly tied to the political situation in Southern Ukraine with the current war. This could have the indirect effect of freezing everything with a de facto statu quo. However this should not affect Nogay used in South-Eastern Bulgaria, Eastern Romania and North-Western Turkey. About one century has past since the collapse of the Ottoman Empire, and about 30 years since the end of USSR. Lot of native people in that region have moved and joined a larger diaspora spread over multiple countries, suing different scritps or alphabetic conventions, so the Nogay language could have felt difficulties to preserve a stable orthography. But at least in Romania, the situation is clear now (and I don't know what Nogays in Bulgaria do: do they still use the Cyrillic alphabet there, esepcially since both Bulgaria and Romania are in the EU, where the Latin script is predominant, only Bulgaria (possibly later Macedonia and parts of Serbia could join; but Serbia is also in transition to use the Latin script in most of its regions, and it already has a very stable standard for transliterations).

Nogay writers could also develop a good and stable translieration scheme if their people agree between their use in Ukraine, Bulgaria, Romania and Turkey, or accept some equivalences between variants of the Latin alphabet. At least for the Latin alphabet, it should be based on an agreemetn between Turkey and Romania, but I've not since any official sources in Turkey, given that most Nogay speakers in Turkey now have transitioned to use standard Turkish. Only Romania seems to have formally recognized the Nogay minority (that is called locally "Romanian Tatars" and not "Crimean Tatars" like in Russia (and in Ukraine, including Crimea, while it was part of USSR and for another 30 years since its independance before the Russian annexion of Crimea). in Ukraine the Nogay people may also be divided now between pro-Russia and anti-Russia. It's not easy for minories to preserve their language notably when they live in troubled regions and have seen their frontiers changing multiple times and recurrent wars. But the best they can do is to develop a standard that allows keeping easy communications eevn if they have to use different scripts or variants of their alphabets.

Dear Verdy p, eur is retired by ISO (https://iso639-3.sil.org/code/eur) Why do you keep re-adding that?

Because it has been published; retirement from ISO 639 does not remove it completely. The code remains frozen indefinitely (and kept in that state for reference). In fact it is marked as "deprecated", see https://iso639-3.sil.org/code/eur (note that ISO 639 is not the only user of these codes and various codes have been "retired" in ISO 639 but kept in BCP47, some of them reappearing later; deprecation jsut means that any documents created tagged with that code remains valid, even if it is not suitable for new documents, and that some of them may be requalified later possibly with another existing code or a private-use code).

Es evidente que tu comprende un texto in interlingua ma es equalmente evidente que tu non lo parla. Interlingua es su proprie lingua, non es francese, per favor cessa de modificar mi traductiones.

No, it was not intentional, but it was linked from a French page, that I need to fix (I initially did not notice the "/ia" suffix at top of page, so I saw you recent edit like a French typo by somone that does not understand French and used some automated corrector). I did not use any bot, it's just the UI that caused this, it was not clear enough in the message I got I French where the link was not fully displayed. I'll fix that affected page in Fernch to detect such case so that it does not trace Interlingua pages.

Also while trying to revert it, you had reverted it in a very short time and created a conflict, so instead of reverting my own edit, it was readded again, so you had to revert it again. Sorry about that.

Understood, thanks for explaining.

Bonjour, je viens vers vous, car vous semblez avoir beaucoup d'expérience sur ce projet.

Je suis intéressé à contribuer sur ce projet depuis plusieurs années. Le problème est que je ne peux presque rien modifier puisque je n'ai pas le statut de « Traducteur ». J'ai remarqué que selon « Project:Translator », ce statut est censé être donné par défaut aux utilisateurs qui effectuent des traductions dans un bac à sable. Or « Help:Sandbox » n'existe pas et je n'ai pas trouvé de bouton « Brouillon » dans le menu. Pourriez-vous donc m'expliquer comment faire? Merci.

Voir aussi : Thread:Support/Translator_right

Voir Translating:How to start/fr (consulter également les liens de base dans la boîte de navigation).

Why are you changing so many other users' user pages? Please let people decide for themselves how they want their userpages to be.

You are also changing user pages, and you're not alone (and the content posted on user page is sometimes very huge via templates that users are not even allowed to edit to fit correctly their page, so they can no longer post their own user content! I am NOT doing that sort of pollution!).

I did not add any content, just made those page a bit more accessible, or fixed basic CSS, just to avoid unnecessary scrolling and a large unsued blank space, but still leaving free space for expansion. Also if there are references no longer working, I do not delete them but comment them out, if this helps cleaning up other things elsewhere (e.g. in error tracing categories, or dependecies that are no longer relevant, or external links no longer working, or gadgets and extensions that are no logner working on this site).

In some cases, users tried to figure out some way to organize their content, but this did not work, or is using deprecated or no logner supported syntax, which also fails to be accessible on other devices (notably smartphones with narrower screens) or just waste space on larger screens (requiring unnecessary scroll down to see the bottom of the page. If there are contents that fill the page correctly on desktop or mobile screen sizes, I do not need to make any change. I helped them, taking into account their attempts, but using modernized and working syntax, without too much complication (and in msot case sthisi s simpler than their attempts: this is the case on the user page that you just reverted, using ugly syntax that is much harder to maintain than what I used, which allows user to focus on working their own content, and add further info if they need, beside just the location box, babelboxes and user boxes).

So I respect their contents, their prefered colors (or fonts as long as this is working), and make sure that other contents generated by template will not limit what other things they want on their user page without using old or ugly tricks (many users do not know the HTML/CSS/mediawiki code rules and tricks; Mediawiki makes some efforts to make it work, but this has price and unexpected effects if there are contents to add/modify/remove later: maintenance is more difficult, so users stop updating their user pages that progressively get low value and are left unused).

If I change someone else's user page, it is only to do routine maintenance, like removing deleted templates or fixing syntax errors. I don't completely change how the user page looks according to my personal preference. Please let other users decide for themselves how they want their user page to be.