Verdy p

fr:Discussion utilisateur:Verdy p
This page is a soft redirect.

Multilingual MediaWiki

Saw your review of Multilingual MediaWiki from last year, thought I'd say hello. I wrote the patch set that introduced the SQL schema and SIL import scripts. Downchuck 02:36, 25 July 2011 (UTC)

That's a severe error ! The SIL data would give you all ISO 639 language codes, without structuring them according to BCP 47 rules. What should have been imported is the IANA database that is the much more complete (and more precise) definition, with also strong stability rules (thanks to the aliases it defines, and the preferences that it documents). Note that this does not mean that ISO 639-3 or -2 language codes are invalid, but they contain lots of synonyms, plus codes that are ambiguous enough that they are of different types (language families, synonyms in ISO 639-2 between alpha2/B and alpha2/T or even with legacy (deprecated) such as "iw" permanently aliased to the preferred "he" in BCP47, and all ISO639-2 or ISO639-3 alpha3 codes aliased to ISO 639-2 alpha2/T codes).

I don't know which schema you created. Was that the initial description? Did you include the language name in the same row as the table of languages or in a separate table containing the various translated (Unicode-encoded!) names of the language (these names may be fed separately from CLDR), without breaking the language ids.

In my review, I proposed several solutions to warranty the stability (including for specific local Wiki language codes, when they don't match the BCP47 standard, but are still needed to maintain a preference or at least a compatibility of interlanguage links). It's highly probable that you did not understand my review (about language code aliases, languages groups, dialects and so on, and how they are effectively structured by BCP47 and NOT by ISO 639), and this has already caused a major bug for interlanguage links in Burmese no longer working (and most probably new issues for Chinese, because it is a macrolanguage)...

Where can I review the implementation? You did not provide any link in your message.

Thanks. Verdy p 05:31, 25 July 2011 (UTC)

Offtopic poems

Hello verdy_p, I almost always read all you write but your comment on bugzilla:39068 was completely offtopic for that report in addition to being very long and complex. I appreciate that you care about translation enough to share your opinions and I'm very sad about the frustration some issues cause you, but I suggest you to instead write on wiki when you have complex thoughts to share (which span multiple issues and take a long reasoning). If you're not comfortable writing on Extension talk:Translate because of the "landlords" or whatever, I suggest you to create a new ns0 page for each of those "essays", either here or on Meta-Wiki. --Nemo 08:00, 10 January 2014 (UTC)

How insulting your post can be. This is not a "poem" or an artistic essay, these are perfectly valid observations, with justifications. They are not inventions. Verdy p (talk) 01:09, 23 January 2014 (UTC)

Note: I just discovered your replay here by wandering, this is definitely not my discussion page, I was never notified of your reply here, your post is about edits made on another unrelated site which is definitely NOT the MediaWiki wiki. You did not even look at my user page here that says that this is NOT my talk page. Did you look at the top of this page???? NO. For this reason your post here was completely unnoticed, you did not follow the common usages. Your post here IS an offtopic poem here in this wiki. Verdy p (talk) 01:11, 23 January 2014 (UTC)

I'm sorry about the misunderstanding, I have a high esteem of literature so for me "poem" is a compliment. I didn't suggest artistic essays, technical essays are perfectly fine here. I stand my point that you would be able to write very useful documents on the wiki, because that's your disposition.

On being OT, I know this is you and this wiki's scope obviously includes MediaWiki and Bugzilla discussions: you edit actively here and it was the most suitable place where to discuss this despite the redirect above (which I saw); if you don't have email notifications enabled for this talk that's fine, my message was not particularly urgent. --Nemo 11:10, 23 January 2014 (UTC)

This is not a mystery, bug SUL accounts and Bugzilla accounts are not linked together. So when say say "I know it's you" it just means that my account here on MEdiaWiki is unified under SUL, it does not indicate you if this is true for all my accounts. In Bugzilla, I just said my home wiki was FR.WP, not this wiki whch may be run by another user. Your check should have said you that MediaWiki-Wiki was NOT my home wiki.

And you're also wrong, I'm extremely rarely active in this MediaWiki wiki. That's exactly why I placed the soft redirect to my home wiki (on the user page AND this talk page). I don't want to be notified by lots of wikis, email notifications are disabled on almost all wikis, except very few where I'm really active (or a few rarely visited wikis for which I've forgotten to create a soft redirect on the user page, when an account was created automatically while visiting these wikis extremely temporarily, most often only to check remote links from other wikis, such as Wikidata or media and category description pages Commons). On most wikis, I've even forbidden users to send me emails: they can do it only on my home wiki or Commons (I prefer not having to manage hundreds of user pages and all their associated talk pages: my SUL account has been activated on nearly 300 wikis, Wikimedia has more than 400 wikis and more are being added, without me being really informed of when this occurs, and I may visit them accidentally but only termporarily).

Well I occasionnaly get to this wiki to read some docs, but rarely to contribute. In that case I will see the Echo notification at top of pages, but I will not receive any email, so I'll be also very late to see the Echo notification when coming back here sometime.

The problem is that you posted on Bugzilla that you had alerted me, this was wrong, I was not notified at all before I read your Bugzilla response.

The normal policy when relying to someone on Bugzilla (if you don't want to reply on Bugzilla directly) is to contact him on his home wiki, as indicated on his user page or talk page. Otherwise you have lots of chance of never have your message read. Verdy p (talk) 02:05, 24 January 2014 (UTC)

Ok, maybe the alerts were 3 instead of 4. Anyway I was certain you would read this message, see above. --Nemo 00:16, 26 January 2014 (UTC)

Universal Language Selector/Announcement Feb2014

Enjoy translating ;-) Regards, --Brackenheim (talk) 14:39, 15 April 2014 (UTC)

Translate insertables too long.png

Please use shorter and/or less tvars. Thanks, Nemo 13:49, 8 July 2014 (UTC)

I maintain them meaningful; in case there are changes that could rewuire translating the target of the link differently. I hate tvars named 1,2,3 that don't help seeing if the target was effectively changed...

They are not so long, and I use some prefixs only when they are common and obvious. I've seen frequently some sentences that required later to have links disambiguated because they are related.

Less tvars ?? Certainly not. We have not enough tvars with links that have to be reedited in each translation when they need changes in the source (pages moved, merged, translated, or a user changing his preferred contact page...)

Note: this image just shows an example where these are not tvars that cause problems (they must be unambiguous in their context of the translation unit), but the translation unbuit which is too long (this is a long paragraph that could be divided in several sentences translated separately).

The worst pages are those that include in a single translation unit all elements in a numbered or bulleted list (that list, including formatting bullets should be hidden and not part of the translation units).

There are many translated pages that use really too long paragraphs that should have been splitted, but this one is not exceptionally long (even if the presence of tvars make it a bit longer, your image shows that it still fits in your screen or any screen with reasonable size, except on some low-resolution smartphones where you'll have to scroll vertically, but these devices are rarely used for translating MediaWiki pages with the translate tool, which is not designed to work correctly and be usable).

So translators use traditional PCs, or tablets, or recent smartphones with good enough screen resolution and this is not a problem.

Low-resolution smartphones are dying (they are no longer sold and will all have their battery no longer working in 2-3 years, so we can safely ignore them, we don't need to invest time for just a short transition period, where ethe same devices are also not usable because of their builtin defective browser with too limited support of HTML and Javascript).

However We should work on making the Translate tool more accessible on phablets and modern smartphones (for now it works correctly only on tablets, and on desktop-size screens with conventional keyboard and mouse and modern PC browsers, it does not work correctly with old PC browsers like IE6 or before, but users should avoid using those old browsers and upgrade to a modern browser). Verdy p (talk) 20:20, 21 April 2015 (UTC)

Extension:Scribunto/Lua reference manual

This is the second time I've had to revert a flood of edits from you that introduce errors, unnecessary examples, irrelevant digressions, and in general the use of several paragraphs where a single sentence will do. I think everyone would be better served by your discussing things on the talk page (where again you need to work on conciseness) rather than you adding 10K of text and me having to extract the few good changes from all the chaff. Anomie (talk) 13:57, 20 April 2015 (UTC)

What ??? These are not "digression", and there are absolutely NO "errors" (really you are ignoring things or have not tested/experienced what is currently documented, which is defective or simply wrong). Errors are only in the text that I corrected.

Scribunto has evolved in its support, in ways that are not documented. And I've NOT added 10K of text!!!

Even if you cumulater things just by diffs, this looks large edits only because I've ordered the functions in the mw.lmanguage package by logical role: the grouping of non-methods before language:methods has been kept, but in each subgroup all direction functions are together as they are corelated, all language code tests are also grouped together, all text transforms are together, all formatting functions for numbers or date are together, and all grammatical functions are together.

Then in each locale-dependent function, where appropriate, I documented those that are limited by a quota (because it was missing and it really affects how these functions work. And this was made in successive small edits, section by section). And this is not docuemnted anywhere else (Lua.org does not document the MediaWiki-specific modules which are evolving too often in undocumented ways! I corrected this severe absence, but you have deleted everything with your blind revert, even if these were just small sentences (not 10K text !).

This is a gross exageration from you, and visibly you don't accept that the MediaWiki library is a collaborative work in progress (and that it has severe limitations or bugs). This is nothing to do with what Lua documents itself, given that it evolves separately (and the version used in Wikimedia is the old 5.1, slightly modified, when original Lua is in version 5.3, and supports more datatypes, including true 64-bit integers or other native datatypes). There are large differences in Lua used in MediaWiki because it is not based on a native C/C++ default implementation but is based on PHP (meaning also that it is only interpreted, and not compiled, and that many functions even in the core Lua library are more or less emulated, with limitations, with the PHP code of MediaWiki, and it depends also on PHP version, notably for supporting numbers and arithmetic operators or math functions, and on how the conversion between numbers and strings are performed).

Your blind revert just perpetuates an old, defective (and sometimes false) documentation of Scribunto (which does not reflect its current state), that does not want to document things, and this is really bad. Developeros of Scribunto modify its code or the MediaWIki library for Lua, without documenting it, but it's up to users like me (or you) to complete this missing documentation (I've tested everything that I added, visibly you do not want to bealive it or are too lazy to test what I wrote and that is effective).

This lack of documentation has already caused problems with many modules in MEdiaWiki that stop working suddenly for unknown and reasons because they are NOT documented anywhere (except in some internal Git servers where most people cannot contribute at all as it is really too much technical or requires specific tools)!

Due to lack of documentation, people spend hours looking for the problem when they realize that Scribunto does not work the way it is documented (with too many false assumptions). Verdy p (talk) 19:42, 21 April 2015 (UTC)

Note also the important disclaimer shown at top of this documentation page: "This manual documents Lua as it is used in MediaWiki with the Scribunto extension."

This documentation page exists in MediaWiki exactly because Scribunto does not work exactly like standard Lua and differences or limitations MUST be documented.

May be you don't like it, but this is a fact, we need this documentation to be in sync with the way the language (and its specific libraries for MediaWiki) are effectively working, even if some of these limitations may be lifted later. For example by porting a newer version of Lua, or making it work in native code, where it could be JIT-compiled to native code instead of being fully hosted and interpreted in PHP: the Lua language is much slower but still faster and uses much less server resources than MediaWiki templates in many cases (except for some MEdiaWiki extensions written in PHP or using external native tools and APIs for database queries, Python scripts, image converters, file content parsers, etc.)

As well the MediaWiki library for Scribunto has numerous bugs and severe limitations. Some of them have already changed without any prior notice and without any documentation, and they caused that many existing Lua modules are no longer work at all: this is the case for the "frame" objects which no longer supports any expansion of special MediaWiki tags, and for the "mw.language" library that has now a quota on the number of languages it accepts, but also in the extremely defective behavior of most language methods in "mw.language" (which are absolutely not conforming to international standards and notably not with Unicode algorithms, BCP47, and CLDR standard data, even though MediaWiki internally includes ICU4C, via its native integration library for PHP!). This MediaWiki library for Scribunto is still in active development and changes in unexpected ways (it is still not stable). Verdy p (talk) 21:16, 21 April 2015 (UTC)

Note: I'm currently in the process of converting almost methods of "mw:languages" to pure Lua, due to the numerous defects of this module (which causes too many wiki pages to fail, and notably on international wikis such as Commons that displays HUNDREDS of languages, more than the current low limit of 20 languages). I have started by the direction methods, number formatters and some multilingual templates used for file description pages and gallery pages. This is because I tested these "mw:languages" methods that I saw their very severe limitations, and even their completely wrong results for some languages ! My opinion is that "mw:languages" is a complete junk of badly written and untested code (this is also true for the built-in list of language fallbacks that are also completely wrong or extremely defective). Before Lua, this support was using MediaWiki templates only, but they were much more correct in their result, than what "mw:languages" returns, when converting these templates to Lua.

Conclusion: we should NEVER use any method of "mw:languages", except as a fallback for some languages recently added in MEdiaWiki, whose support is still not ported to pure (and more efficient!) Lua.

For testing this development I do it in Wikimedia Commons, because it is a really international wiki (this could be done also in MediaWiki-Wiki, but there are not enough active users for all languages here, to see how things should work, or to signal incidents and tricky cases). Many users in Commons have thanked me for solving these bugs or limitations. Verdy p (talk) 21:39, 21 April 2015 (UTC)

Consider this a final warning: the next time you introduce an error to the Lua documentation or make an inappropriate post on its talk page (or any other talk page), you will be blocked. Jackmcbarn (talk) 19:46, 27 April 2015 (UTC)

I have not introduced any error, this was things that were NOT documented but effective !

Visibly Anomie has just convinced you indirectly, but I had not seen you before here on this subject.

I've not violated any rules when making these small additions (one short sentence per affected function, it's not 10K as Anomie affirms).

It is not in the policy of Wikimedia to block someone that makes *honest* contributions, in very good faith, and that fave proven to be useful.

Anomie just continues to propagate things that are obvously wrong or not working at all the way it is documented and that causes unexpected errors (and loss of time by Wikimedians seeeking for reasons explaining the problems).

I had received many thanks (on several wikis) for these documentation edits before Anomie started his unjustified war against me. I was not alone even if this was me that made this work Anomie does not want (and he was up to your message) completely alone...

But visibly, we'll have to create separate documentation (just like on German Wikis that also find this one completely useless the way it is maintained). We can't trust MediaWiki wiki for that.

Verdy p (talk) 20:08, 27 April 2015 (UTC)

Edit warring

Please avoid edit wars like this on translations. Translation is not an exact science, and more so for names: if there's a disagreement maybe it's better to discuss a bit more. I value your contributions possibly more than anyone else, so I'm especially sad that I'm once again considering to use a certain button here too. Nemo 18:50, 6 January 2021 (UTC)

This is not an edit war by me, but Thibault was modifyikng instantly every edit I made (only Thibaut made this war, I made *single* edits, that Thibaut warred against instantly, I did not see any edit warning, except minutes later (once I had all edited in the translate interface, where we never see any "history", until we get back to the full page). Verdy p (talk) 18:58, 6 January 2021 (UTC)

And there was a discussion only after that, to which I participated (but Thibaut had already reverted before going there; then only I was "pinged" by this talk). Verdy p (talk) 19:00, 6 January 2021 (UTC)

Oh I see that you've applied a block in TWN: saying that I did that "without discussion": but I replied to the discussion initiated here by Thibaut. And my edits were done before he started to talk here. There was NO talk from him (or anyone else) in TWN. Verdy p (talk) 19:24, 6 January 2021 (UTC)

As well, each time I try to discuss or even signal problems, they are ignored or I'm publicly bashed. This happens even if many people approve what I did. I've signaled another thing here, but not reply as well. Who doesn't want to talk? Verdy p (talk) 19:26, 6 January 2021 (UTC)

[WMF Board of Trustees - Call for feedback: Community Board seats] Meetings with MediaWiki and Wikitech communities

The Wikimedia Foundation Board of Trustees is organizing a call for feedback about community selection processes between February 1 and March 14. While the Wikimedia Foundation and the movement have grown about five times in the past ten years, the Board’s structure and processes have remained basically the same. As the Board is designed today, we have a problem of capacity, performance, and lack of representation of the movement’s diversity. Our current processes to select individual volunteer and affiliate seats have some limitations. Direct elections tend to favor candidates from the leading language communities, regardless of how relevant their skills and experience might be in serving as a Board member, or contributing to the ability of the Board to perform its specific responsibilities. It is also a fact that the current processes have favored volunteers from North America and Western Europe. In the upcoming months, we need to renew three community seats and appoint three more community members in the new seats. This call for feedback is to see what processes can we all collaboratively design to promote and choose candidates that represent our movement and are prepared with the experience, skills, and insight to perform as trustees?

In this regard, two rounds of feedback meetings are being hosted to collect feedback from the technical communities in Wikimedia. Two rounds are being hosted with the same agenda, to accomodate people from various time zones across the globe. We will be discussing ideas proposed by the Board and the community to address the above mentioned problems. Please sign-up according to whatever is most comfortable to you. You are welcome to participate in both as well!

• Round 1 - Feb 25, 4:00 pm UTC
• Round 2 - Mar 4, 4:00 am UTC
• Sign-up and meeting details: Wikimedia Foundation Board of Trustees/Call for feedback: Community Board seats/Conversations/MediaWiki and Wikitech

Also, please share this with other volunteers who might be interested in this. Let me know if you have any questions. KCVelaga (WMF), 14:38, 21 February 2021 (UTC)

Editing my posts

Do not edit my posts, especially to change code examples in them. If you think they are inadequate or incorrect for whatever reason, add a comment of your own with the corrections. 「ディノ奴千？！」^{☎ Dinoguy1000} 09:19, 30 May 2023 (UTC)

There's a reason: you sugggest replacing a separator to glue the two links wuthout any separator between them... Verdy p (talk) 09:42, 30 May 2023 (UTC)

I know exactly what my suggested code does, and unlike you, I know exactly why I suggested it: in this case, because the original poster also posted code that would result in run-on links. It's quite obvious how to change the code to avoid the links running on, and even if they weren't able to figure out how, I'd expect them to simply ask for modified code or a hint at what to do. 「ディノ奴千？！」^{☎ Dinoguy1000} 09:28, 31 May 2023 (UTC)

Yes but he wanted to have separators between links, not gluing them. Verdy p (talk) 09:42, 31 May 2023 (UTC)

Parser

Just following up on our discussion about the parser, do you know anywhere where the changes to the legacy parser are being documented (if anywhere). If there are changes to how parsing works, such as the non-linear parsing we were talking about, I definitely want to keep up to date on them. Thanks! – Robin Hood  ^(talk) 19:16, 25 June 2023 (UTC)