About this board

Previous discussion was archived at User talk:Tpt/Archive 1 on 2015-08-10.

ws2wd ne répond plus… (oskour)

Hsarrazin (talkcontribs)

Bonjour Tpt

depuis 2-3 jours, je ne peux plus du tout récupérer les données depuis le header de wikisource…

symptôme : dès le clic affichage du message "Convertion to Wikidata failed: "parsererror""

voir par exemple sur Q108311084 (les articles de la RDDM n'ont jamais posé de problème).

c'est très ennuyeux, car le travail commencé de transfert sur wikidata des données des livres et textes des recueils et articles est très long sans cet outil…

Tpt (talkcontribs)

C'est corrigé. Il y avait une erreur de certificat HTTPS car le serveur n'avais jamais été mis à jour depuis plusieurs années.

Hsarrazin (talkcontribs)

aoooooooooooohhhhhh !!!! Merci !!!!

ça commençait à sérieusement m'inquiéter, et te sachant très occupé, je ne savais pas si tu aurais le temps de voir ça

Reply to "ws2wd ne répond plus… (oskour)"

pb avec l'outil ws2wd sur les textes d'un recueil

Summary by Hsarrazin

désormais dépassé… voir maintenant Topic:Whnpt6nkdj8uxs07

Hsarrazin (talkcontribs)

Salut, le script ne marche pas du tout, ou plutôt affiche immédiatement "Convertion to Wikidata failed: "parsererror" sur les textes de ce recueil... https://petscan.wmflabs.org/?psid=20148209

mais ça n'est pas ''le script'' qui a un problème, puisque ça marche sur ceux de https://petscan.wmflabs.org/?psid=20148215

et ça n'est pas non plus une question de saturation des serveurs (ce qui arrive), puisque ça marche sur d'autres textes...

est-ce un problème lié à la page d'index ? ou autre chose ?

merci pour ton aide :)

Hsarrazin (talkcontribs)

alors, après plusieurs jours, j'ai finalement pu traiter les poèmes de "Dans les brandes, poèmes et rondels", mais j'ai ce soir le même problème avec ceux de "Les Kitharèdes" (Q19211459).

je n'arrive pas du tout à comprendre pourquoi… les symptômes sont exactement les mêmes, un message immédiat "Convertion to Wikidata failed: "parsererror" lorsque je clique sur le bouton de récupération…

Reply to "pb avec l'outil ws2wd sur les textes d'un recueil"
Lectrician1 (talkcontribs)

Hi! I'm interested in using GraphQL API you made for Wikidata. But, there seems to be a lot of functionality missing such as Mutations to edit items. Is there a repository for the API that I could contribute to to build out more functions?

Tpt (talkcontribs)

Hi! Most of the code here. It depends on an old version of graphql-php. I wrote it as an experiment and it's mostly unmaintained. Feel free to contribute if you want or just fork it or even reimplement it in an other language. I am not maintaining it anymore and I would be very happy if someone makes it alive again!

Reply to "Tptools GraphQL questions"

Pages with maps don’t render correctly on Dagbani wikipedia

Masssly (talkcontribs)

Hello User:Tpt, I was wondering whether you could help with an issue on Dagbani Wikipedia: they use the Databox module to generate infoboxes. Pages such as Jisonayili and Ankara, that contain maps don’t render correctly. Thanks. -~~~~

Jon Harald Søby (talkcontribs)

There is a lot of problems with Maps currently because of a refactor happening (I believe phab:T288730 is the right ticket), so this is happening all over the place. In other words: The module in the Dagbani Wikipedia is not broken, the maps themselves are.

Masssly (talkcontribs)

Oh, I was absolutely convinced that there was something wrong with the module. Thanks for the feedback @Jon Harald Søby. -~~~~

Reply to "Pages with maps don’t render correctly on Dagbani wikipedia"
VIGNERON (talkcontribs)
Tpt (talkcontribs)

C'est corrigé : Special:Diff/1381334827. J'ai l'impression que dans le VIAF tout les entrées de la bibliothèque du vatican utilisent le nouveau format d'indentifiants.

Reply to "User:Tpt/viaf.js"
Robby (talkcontribs)
Reply to "MediaWiki_talk:Gadget-slurpInterwiki.js#Save_error:_Unknown_site:_nbwiki"
RolandUnger (talkcontribs)

Your bot TptBot makes a wrong phone formatting in case of extensions. For instance, in case of Maritime Museum of San Diego (Q3330638) it changes the correct number "+1-619-234-9153 ext. 101" to the wrong one "+1-619-234-9153;ext=101". The changed format does not match the regular expression of phone number (P1329).

Tpt (talkcontribs)

Hi! Thank you for pointing out this problem. Do you know why the regular expression has been crafted this way? The english description of the property states telephone number in standard format (RFC3966), without 'tel:' prefix and the RFC 3966 enforces to use the";ext=" syntax. I have opened a discussion on the property talk page about it.

RolandUnger (talkcontribs)

Unfortunately I was not involved in the establishment of this property. When it was created the property was of string type because the phone number-number model did not existed yet. At at this time nobody made a hint on RFC 3966 -- surely because this is not a human-readable format. In December 2016 a first regular expression was added but no hint on RFC.

On Jan 29, 2018 user:Tpt added a hint to RFC 3966 but he did not changed the regular expression. In April of this year user:Verdy p changed the regular expression in a non-RFC compliant manner but in a human readable manner as it is used on many wiki pages.

Verdy p (talkcontribs)

I did not change the format for extensions, it as ALREADY specified without using ANY semicolon or equal sign (as in the RFC). What I did was only to validate the main part of the phone number, and I left the support for extension unchanged. In fact the RFC allows a LOT of extensions for phone numbers, each one separated by a semicolon, and specified as a property (i.e. a key=value pair, with a unique key, but keys in arbitrary orders). We can't use that in Wikidata or we won't be able to validate the format. So, given this RFC if we want to add support for an arbitrary list of properties, and check the uniqueness of these properties that are also unordered, we should better have a separate property in Wikidata, outside the phone number itself.

The RFC 3966 format is an encapsulation format, which is not what the ITU standard prescribes. And there are other competing encapsulation formats, including in other RFC! (which is still not part of any BCP, so that it can be deprecated at any time). The number of properties is growing with the number of transport protocol and virtual service providers on the net, and even phone numbers are insufficient for them as they can use other letters, or can require the use of authentification (for billing, or for privacy, or for legal reasons), or can be used to group calls in a meeting with more participants), or can require additional protocol format (e.g. for audio and video codecs).

This RFC 3966 is not suitable here. We just want a single basic format. And until now, the basic extension mecnims has never used the semi-colon or equal sign, so the ;ext=(\d*) syntax is clearly invalid, it should just be / ext\. (\d*)/ as it was (with optional space or dot separators).

Adding RFC 3966 support would be wrong in Wikidata and in fact impossible to check correctly. We don't want such encapsulation just like we don't want the MIME format in a single property value. The only allowed encapsulation format is for URIs (but then we don't check the URIs except accepting only a few URI schemes and enforcing a policy about the host.domain part with blacklists against spam).

Note: I added the support for ";ext=", it was a minor change (until now the ";" and "=" were invalid, this was never present or requested before, and my improvement to the regexp then did not took this into account). This does not change at all the capture groups numbers, so phone number parsing is unchanged, and it now allows a bot to reformat the validated phone numbers if needed to use ";ext=" instead of " ext. ", or "/ext ", or just "x".

Also I did not change the following rule: only ONE phone number must be specified, you need to use separate properties to specify several phone numbers (possibly qualified for distinct usage). The change was also applied for fax numbers.

I also updated the reference URL that points to a regexp test online which is also updated with this new version.

Reply to "Wrong telephone number change"
Csisc (talkcontribs)

Dear Mr.,

We are organizing a French-speaking session of WikiCite 2020 online on 27 October 2020 from 15:00 to 19:00 UTC. Further information on the preliminary program can be found at https://docs.google.com/document/d/1E_a7I6PRYUlfdw6aPqR4X9FMgwsiXBpsZc0_AJLPINU/edit?usp=sharing. We are still finding a speaker that can introduce Wikidata and the bibliographic metadata it currently involves to the session audience. I ask if you can present Wikidata during the session.

Yours Sincerely,

Houcemeddine Turki

Tpt (talkcontribs)

Bonjour Houcemeddine, merci beaucoup de l'invitation. Cela me touche beaucoup. Malheureusement, je risque d'être pas mal occupé à ce moment là et préparer une présentation fera beaucoup. Je ne suis pas non plus le meilleur "présentateur" à ce sujet. Tu peux demander à VIGNERON (talkcontribslogs) ou hsarrazin (talkcontribslogs) qui sont plus proche des bibliothèques que moi.

Reply to "About WikiCite 2020"

Hello, batch errors in entry for gene HERC2

TiagoLubiana (talkcontribs)


The bot made many wrongful edits Q18033537, would you mind taking a look at it?


Tpt (talkcontribs)

Hi! Sorry for that. My bot is just formatting phone numbers, it seems that the facts where originally introduced by Ezarate (talkcontribslogs) (example).

TiagoLubiana (talkcontribs)

No problems, thanksǃ

Reply to "Hello, batch errors in entry for gene HERC2"

Update of lb-translations of Gadget-slurpInterwiki.js

Robby (talkcontribs)
Jon Harald Søby (talkcontribs)

Next time it is probably easier to put {{Editprotected}} in the section, that way any admin going through the category can see it. :-)

Robby (talkcontribs)

Thanks I've added now the template Editprotected

Reply to "Update of lb-translations of Gadget-slurpInterwiki.js"