Mostly active in adding new Language codes to Wikidata
User Details
- User Since
- Oct 6 2014, 7:47 AM (468 w, 1 d)
- Availability
- Available
- IRC Nick
- mbch331
- LDAP User
- Mbch331
- MediaWiki User
- Mbch331 [ Global Accounts ]
Mon, Sep 18
Fri, Sep 8
No problem for me. Don't even know why I added it.
Aug 26 2023
Aug 18 2023
It was never removed from CLDR, so CLDR doesn't need to be repatched.
I rebased my patch for Wikibase on the current master.
Not sure if anything else needs to be done (besides approving my Wikibase patch). Not up to date with the steps that are needed nowadays for adding new monolingual languages.
Jul 26 2023
Jul 19 2023
Issue has been resolved somewhere yesterday.
Status page had no message there was a problem, but I did notice the Wiki error responses were much higher, so there definitely was an issue.
Jul 18 2023
Jun 7 2023
Jun 6 2023
On nlwiki I see this on all pages with a DEFAULTSORT and we use this heavily on pages about people. We want to sort them on lastname and the article name is Firstname Lastname.
We can't edit the value for DEFAULTSORT in VE, since it's a non-existing template for VE. And in the category section of VE, no value is visible.
May 26 2023
Issue seems to have resolved itself.
May 20 2023
Issue also occurs on nlwiki
May 4 2023
Hmm...
The commit is already there, but failing on something not directly related to this change.
It can't find the DonationInterface extension.
I can't help with that.
I know a bit on where to add language codes in CLDR, but not about the tests that are done by Jenkins
Apr 29 2023
The did the trick. (And of course changing <cite> to <citation>)
Still see the citation tag and the date isn't updated
Citation doesn't work on nlwiki. It then litterally shows the tag.
Mar 21 2023
I've removed the mapping for gsw/als. I added it based on a request on the talk page of the gadget.
Mar 16 2023
Structured data has been cleaned too.
Mar 15 2023
Checked the current live code and issue has already been fixed somewhere in 2019.
So it's only correcting existing data.
For the information template this has been fixed.
For the Structured data I filed a Bot request: https://commons.wikimedia.org/wiki/Commons:Bots/Work_requests#Replace_Date=1970-01-01_in_Structured_Data_of_Wikiportret_uploads
In the end the users uploading the file to commons are responsible. (This includes me). On uploading the file, a pre-filled template is placed in the text field. The users needs to fill in the missing information, categories and press submit. (I must admit there are uploads by me in the search results, so I have been negligent too)
And the date isn't invented from scratch. Unix timestamp 0 is 1970-01-01.
I'll make sure that in a new version of Wikiportret the date field is emtpy if it's 1970-01-01
Nov 16 2022
Just tried it with safemode=1 and then the issue doesn't occur. So it's a gadget or userscript that causes the issue.
Disabled all my userscripts and enabled them 1 by 1.
No problems, until I enabled User:Magnus_Manske/authority_control.js by @Magnus
Nov 13 2022
Oct 23 2022
I need to adjust my script so it sends mail using the smtp server for tools.
And I need to migrate my wget command to curl, but that's an easy fix.
Oct 14 2022
Sep 28 2022
Is already available: https://www.wikidata.org/w/index.php?title=Q4115189&diff=1738465680&oldid=1737723756
Aug 22 2022
Aug 12 2022
May 11 2022
@Manuel: The term termbox languages means Labels/Aliases/Descriptions. When added, they are also available for Monolingual properties. They won't become available for Lexemes on the other hand.
May 10 2022
Feb 1 2022
Jan 14 2022
Nov 5 2021
Nov 3 2021
Oct 29 2021
Oct 26 2021
Sep 13 2021
But is there a real use case for monolingual properties in those languages? If there's only a one time use, then you should use mis (miscellaneous), because changing the code so minority languages can be used will make this a significant change.
If there are valid use cases then please provide them, so WMDE can make a better judgment if it's worth changing the code to make this possible.
Besides langcom approval, we also need language codes. So far only Gallo has been provided.
Sep 12 2021
@Esc3300 LocalNamesEn.php is part of CLDR. That's not a WMDE extension.
The corresponding change was approved by @Raymond and not WMDE
Aug 29 2021
It's not the query service gui that adds the +
When you use the bigdata interface the + gets added as well.
Aug 28 2021
The problem is that the + gets encoded again. It becomes %2B
Aug 14 2021
Aug 11 2021
Aug 6 2021
@Eugene233 When requesting new languages always specify what you want to use them for: Monolingual properties or Lexemes or Labels/Description/Aliases as the developer needs to know where to add them in the code.
If you want to use the language outside Wikidata, you need to contact LangCom (not via Phabricator) what you need to do to get the language added for use on all Wikimedia projects.
Jul 21 2021
Jul 19 2021
Jul 18 2021
Jul 17 2021
@Amire80 What's your view on this?
Jul 8 2021
Jul 3 2021
Jul 2 2021
This is blocked on LangCom approval for the remaining languages.
Jun 29 2021
Jun 27 2021
@Esc3300 My patch was denied for 2 reasons:
- I used da instead of nl (which has been fixed)
- There is not enough proof of consensus in this task (this is something I can't fix.
Added missing translations. Language codes that are present in CLDR need to be updated upstream, language codes not present in CLDR can be added to LocalNamesNl.php
Jun 26 2021
No. It's only available for monolingual properties. Labels/aliases/descriptions aren't properties and thus not supported. If it's needed, a new ticket is needed for that.