User talk:Verdy p

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 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)