From Meta, a Wikimedia project coordination wiki
Jump to navigation Jump to search

Comments on Modifications from Tech News: 2018-18[edit]

Welcome at your comments. --Rical (talk) 19:04, 30 April 2018 (UTC)

Translation: please clarify Background[edit]

Under Background, it says “...Our foundation will be [[$hays|Hay's Tool Directory]], which describes over 450 tools through ...”.

Which of the following is safe to translate into? “...Our foundation (a) is going to move away (b) transfer from (c) discontinue using [[$hays|Hay's Tool Directory]], ...”? My assumption based on the description given thereinafter. ----Omotecho (talk) 08:30, 19 May 2018 (UTC) Omotecho (talk) 08:30, 19 May 2018 (UTC)

I think something more like "...we will will start from [[$hays|Hay's Tool Directory]], ...". "Foundation" here is used in the sense of w:Foundation (engineering) meaning the base on which a larger structure will be built. --BDavis (WMF) (talk) 20:02, 19 May 2018 (UTC)
@BDavis (WMF):, yes, I agree we avoid the term “foundation” to save confusion. So, “...start from...” sounds very good to me. Regards, ----Omotecho (talk) 21:19, 19 May 2018 (UTC)

A few points/questions[edit]


I'm not sure if I'm writing this in the right place. A bit of background, I write quite a lot of documentation for Wikidata and previusly worked with Hay on trying to create a tool to record documentation on Wikimedia projects some years ago. A few points/questions:

  • The other WMF project to document resources that I'm aware of is the Wikimedia Resource Centre, how will these two resources interact? There is very likely to be at least some things documented in both places and its not clear where the boundary would be. E.g Flick2Commons is a tool, but also there are instructions on how to use that tool, it seems likely that the tool and instructions would possibly appear in both Wikimedia Resource Center and Toolhub. I guess my question is how will these interact with each other? Will there be any shared software between the two resources? How much crossover will there be? If there is likely to be a high percentage of duplication of resources could these be combined into one site? What benefits and costs are there to keeping them seperate or combining them?
  • What costs and benefits are there to creating a database seperate to Wikidata? Looking at the data model it appears as though these fields could fit into Wikidata, could it be possible to hold the information for the Toolhub on Wikidata, with the Toolhub interface simply being a Wikidata explorer, perhaps Mounmental could offer an idea of the kind of thing that would be possible.


John Cummings (talk) 09:17, 29 May 2018 (UTC)

Hello John Cummings,
  • A very good question; thankfully I am also familiar with the Wikimedia Resource Center. The specific example you give has a fairly straightforward answer – tool documentation would be coupled with the tool and thus included as part of that tool's record in Toolhub. But in general I view the Resource Center as a superset of Toolhub, meaning anything in scope for Toolhub is also in scope for the Resource Center. I've talked this over with María, and the current plan to prevent duplicate effort is to embed a tools section for each audience view (for contributors, for affiliate organizers, etc). To make this possible, each tool will be annotated with an audience designation according to the same scheme used by the Resource Center, and the Resource Center will automatically pull this data. I don't know if this is the best approach, but it's the least complicated one and it helps keep the two resources integrated.
    • On the specific question of shared software – not at first, but something I would like to look into for the long term. The challenge in building any software like this is making it purpose-specific but not too purpose-specific (so as to exclude even the possibility of supporting other use cases). With Toolhub, my goal is to support the particular use case of documenting software tools well, but in a way that sets up best practices for the many other use cases of the Resource Center.
  • The main precondition is the Wikidata community deciding that tools are inherently notable and should be documented on Wikidata. While I think there is a clear value proposition in creating a database of community-built tools, I don't think the responsibility for maintaining this database should be imposed on any particular volunteer community – especially if such an imposition results in data being rejected. (It's worth noting that some of the data fields proposed for Toolhub don't seem like good fits for Wikidata, such as the "related topics" field that is basically a generic keywords field.) That said, the data model does provide a field for Wikidata ID, and Wikidata could be used for supplementary data.
Harej (WMF) (talk) 06:01, 30 May 2018 (UTC)
Thanks very much @Harej (WMF):, all good points. If the Toolhub had fairly static URLs for each tool then a Wikidata property could be created to link through to the Toolhub page for each tool. This may allow you to understand coverage of existing tools on Toolhub and make pretty graphs and maps and stuff. John Cummings (talk) 15:32, 31 May 2018 (UTC)

WikiProject Women in Red[edit]

Would you consider doing a consultation with our community to help us document which tools we're using? We may be unaware of tool names, though we use them nonetheless. The other language versions of Women in Red have asked for this saying they would benefit from understanding what we're using as they appear to have less automated systems. Thank you. --Rosiestep (talk) 08:10, 31 May 2018 (UTC)

Rosiestep, I'm happy to help. Do you have links to the tools you are currently using? What I would like to be able to provide is the ability for groups such as Women in Red to have their own custom-built lists that they can share with their communities (including counterparts in other languages). Harej (WMF) (talk) 21:23, 31 May 2018 (UTC)
Unfortunately, we don't have such a list, Harej (WMF), and would need help to develop it. Certainly, as you say, one of the main objectives would be to share it with our counterparts in other languages. --Rosiestep (talk) 21:55, 31 May 2018 (UTC)

Internationalization and multilingual issues[edit]

If have one question and one remark/proposal.

On supported_languages I wonder how to specify that a tool supports many many many languages.

  • I understand that I might supply an Array of some particular language codes.
  • The major functionality of my lintHint gadget works with some 200 or more languages, I don’t know which and how many, since it utilizes the linter system messages provided by MediaWiki.
  • The mul is defined by ISO 639, but that is not translated into a message, even more not a reasonable explanation, and it probably won’t match a search for all Toolhub entries supporting French or Portuguese since mul does not match fr nor pt.
  • Perhaps a * language code becomes necessary, matching all language queries and explained as “almost every language”.

The other issue is that I am astonished about the JSON model.

"description": {
          "type": "string",
  • I would have expected something like:
"description": {
          "oneOf": [
              "type": "string"
              "type": "object",
              "items": {
                "type": "string"
            } ], 
  • Looking at mw: Extension:TemplateData #InterfaceText (string or object) I would expect that I can provide various components either as string in one particular but unspecified language (hopefully English) or I would offer a map of strings, or at least one explanation and the assigned language code.
  • BTW TemplateData is a pretty good example for a possibly multilingual description of a utility.

Let’s take my lintHint gadget as an example. I would like to advertise it as follows:

"description": { "en": "Show LintErrors analysis live.",
                 "de": "Zeige LintErrors-Analyse live.",
                 "it": "Mostra analisi degli errori di Lint in diretta." },

(you might have a look at line 118 of the code which uses exactly that to introduce itself, depending on current user language).

The same as for descriptive texts goes for documentation pages. The current data model specifies that there is one and only one documentation page url as a kind of tool homepage.

The same as for these two components goes for many others. I would expect that a user has chosen to turn the GUI of Toolhub into an available language best fitting to his preferred tongue, or at least specifies a language preference. Then all multilingual items try to find the best match, with fallback to English, and if not English then the one and only chunk that is available. This goes for:

  • title
  • description
  • url
  • keywords
  • subtitle
  • feedback_url

Screenshots, video, additional information and others planned for later extensions are subject for localization as well.

Greetings --PerfektesChaos (talk) 12:57, 5 June 2018 (UTC)

Hello PerfektesChaos, thank you for your question. For the lintHint gadget, it would probably make sense to just mark it as supporting every language – "*" would be the way of marking that. Even if your tool doesn't support literally every language, it's probably close enough. (I'd be interested in knowing if it would somehow be misleading.) As for multilingual support, you are correct to point out that its structure implies only one language. This is intentional, to help keep the files straightforward. Instead of having every language in one file, and having to keep all the translations in sync in that file, the original record is just in one language. Then, the record is synchronized with, where volunteer translators can translate the fields into different languages. This way, translators can more easily find the strings to be translated and it is clearer what is the "official" record and what is a translation. As for tool documentation, in the planned data model, this is covered through annotations – a community-editable adjunct to the tool records – and it is possible to supply multiple links. I hope this addresses your concerns; please let me know if there is anything that should still be addressed. Harej (WMF) (talk) 19:55, 12 June 2018 (UTC)
Some text fragment translating poeple on translatewiki do not match my point.
  • url is split up into several links (URL or wikilink for simplification):
  • The best match of available URL with the current user language shall be offered, not somewhere hidden in some English annotations a remark that well if you do not understand English but German you might find a German covering URL. And nds or gsw might catch a fallback into the nearest appropriate language, as we are used to do in wiki software.
  • It is not a matter of text translation. It is not translatable, it does not provide all languages but some particular, the URL or links might point to various sites.
Same for:
  • feedback_url
  • Screenshots
  • video
Regarding synchronization of various translations I regard it as even better when English base description text and official translations by the provider are kept in one place. The descriptions are not made for eternity, like a phrase. Features and capabilities may be added or removed from purpose description and annotations. They are subject to dynamic development. I worry about diverging feature descriptions when updating the one and only English base description of the gadget and some diverging translations nobody knows about where and how to update them.
Instead of having every language in one file, and having to keep all the translations in sync in that file, the original record is just in one language. – Oh, yes, it is one and only one file and one record only. However, the data type of such elements is either string (probably English) or object (multilingual, with language codes pointing to various languages). That is even more “all the translations in sync in that file” altogether than having the English description of current cabapilities in the one and only file and the updates in other language somewhere on translatewiki. Please have a look at TemplateData which has one single definition only but multilingual texts inside.
Greetings --PerfektesChaos (talk) 08:42, 13 June 2018 (UTC)
Hello PerfektesChaos. If I understand your point here correctly, it’s that if there is only one field for the URL, there is a risk that alternate language versions end up being hidden. And that this is especially a problem with gadgets and user scripts since you link to specific wikis. I agree in principle that supporting multiple URLs based on preferred language would be better, and that this is different from tool metadata. However, since this version of the data model is supposed to be backwards compatible with the old one, that means the behavior of the “url” parameter is supposed to remain the same – just a URL and nothing more. However, for version 2.0.0, we can consider a “url” parameter that gives equal support for multiple URLs, including language variants. Would that address your concern?
As for other fields: I agree that screenshots and videos supplied should be annotation with the language, with screenshots and videos supplied depending on the language. As for feedback_url, is your idea that there are different destinations for leaving feedback depending on the user's language? Wouldn't that result in feedback being scattered in different places instead of organized for the convenience of the tool developer? (I'm interested in knowing if there is an angle I am not considering here.)
Harej (WMF) (talk) 03:47, 19 June 2018 (UTC)

It's a bit unfortunate that the discussion is split on two talk pages on multiple topics. I've commented about these matters on Talk:Toolhub/Data_model#Comments_related_to_languages_and_translation. --Nikerabbit (talk) 13:09, 14 June 2018 (UTC)

Great project![edit]

I just wanted to say, that I'm really happy that your doing this project! The huge pile of unsorted, unfindable and messy situation of tools, gadgets, etc. is in my opinion a big an important problem. This will could a huge improvement. After this we only would need Gadgets 2.0. ;) -- MichaelSchoenitzer (talk) 14:35, 8 June 2018 (UTC)

What I do[edit]

I edit articles, upload files, informally patrol vandalism, I organize people, online or offline, train new editors, or new trainers, assist veteran editors, write simple code, define words on Wiktionary, create items on Wikidata, refine items on Wikidata, offload data from Wikipedia to Wikidata, migrate files from Wikipedia to the Wikimedia Commons, approve Pending Changes, and so on.

One of my efforts is to make every article have the same feel and look as every other article: continuity of style and flow.

What tools do you have for me to improve my workflow? Having fun! Cheers! Checkingfax (talk) 04:13, 14 June 2018 (UTC)