|
Archived discussions
|
How to get correct coordinate location?
[edit]
- At Wikivoyage the traveller comes first, not whatever purpose is served by listings being integrated with Wikidata. The traveller obviously needs points of interest to be placed accurately on a map, and if you have to remove the Wikidata identifier to accomplish that, so be it. -- AndreCarrotflower (talk) 04:36, 18 August 2020 (UTC)
- Fixed. You had the same lat+long hardcoded in the marker template (probably copy+pasted?)... -- andree.sk(talk) 06:29, 18 August 2020 (UTC)
- Thanks for this, @Andree.sk. From the edit summary, it sounds like Wikidata was the solution, not the problem. WhatamIdoing (talk) 20:27, 18 August 2020 (UTC)
- Yup... :) -- andree.sk(talk) 05:38, 19 August 2020 (UTC)
- Wow, thanks guys, I appreciate it, and I'll try to learn from that. Grateful for all the help.Lazarus1255 (talk) 05:48, 19 August 2020 (UTC)
- Thanks for this, @Andree.sk. From the edit summary, it sounds like Wikidata was the solution, not the problem. WhatamIdoing (talk) 20:27, 18 August 2020 (UTC)
New opening hours properties on Wikidata
[edit]There are two new properties on Wikidata that might be useful for Wikivoyagers, too: opening time (P8626) and closing time (P8627). These properties can centralize and allow for adding references to opening hours information across Wikivoyage language editions. It also exposes the data to a large userbase of Wikidatans, who can help keep the information up-to-date. NMaia (talk) 10:26, 21 September 2020 (UTC)
- Hi @NMaia: Thank you for letting us know about this news; hopefully the new feature can be mutually beneficial.
- There is a point of consideration which you and your fellow Wikidatans may not be aware of: on Wikivoyage, we have standardised formats for opening hours, including specific abbreviations for days of the week and month, and we use day ranges rather than daily opening hours (e.g. "M-F 9AM-5PM, Sa Su 10AM-6PM", not "Mon 9AM-5PM, Tue 9AM-5PM, Wed 9AM-5PM,..."). We also use a mixture of 24-hour and 12-hour clocks, depending on the most prevalent system in the geographical location concerned. For example, listings in the USA use the 12-hour clock, while listings in France use the 24-hour clock. Full details of the policy can be found at WV:TDF.
- Will you be able to ensure that this policy is adhered to? Regardless of the format Wikidatans will use to input the data, we will need the hours to display on Wikivoyage in the required format, and as stated already this varies across our articles.
- I think it's a good thing to collaborate across projects, but in this case there has to be regulatory alignment of some description in order for this to work. There may be appetite in the Wikivoyage community to update our TDF policy, or maybe Wikidata will adopt our policy, or perhaps there is some sort of software to convert WD inputs into the required WV format. But however it's done, there needs to be interwiki standardisation.ThunderingTyphoons! (talk) 11:54, 21 September 2020 (UTC)
- I think it is possible for code to give the relevant outputs based on machine readable data on WD. Hobbitschuster (talk) 12:45, 21 September 2020 (UTC)
- Yes, I've been told it can be done, particularly with Lua modules. NMaia (talk) 02:01, 22 September 2020 (UTC)
- Even if it weren't, it's not terribly important. We can import the data into the listing template, and manually correct the format. I've tried importing some Wikidata records to pre-populate the listing, and it can be a significant time- (and hassle-) saver.
- I don't think that Wikidata should ever be held responsible for following our formatting style. Besides, what if a different community had a different style? We should feel free to use the information, and to share information with them, but turn it into something that works for us here. WhatamIdoing (talk) 15:44, 22 September 2020 (UTC)
- Yes, I've been told it can be done, particularly with Lua modules. NMaia (talk) 02:01, 22 September 2020 (UTC)
- I doubt it is worth the trouble. WV formats are not sacred. This might be a good time to improve them. Pashley (talk) 12:15, 22 September 2020 (UTC)
- The format of the property seems to be quite flexible, as shown by examples at Wikidata:Property proposal/opening hours, but there might be important special cases where the Wikidata format is more convoluted than the Wikivoyage one. In any case, we need code to get the info we want and format it in some way. Perhaps the result of a well written database query is suitable for us, but I'd try to write that query/code first and look at how more complicated entries get to look like before we deem a Luo module is unnecessary. –LPfi (talk) 12:44, 22 September 2020 (UTC)
- Nobody said they were sacred, I even said that we might be willing to change them. But this will need to happen across the whole site as a new standard, not be done piecemeal so that we have a bunch of different formats in use.--ThunderingTyphoons! (talk) 12:51, 22 September 2020 (UTC)
- We kind of already do have a bunch of different formats in use. There's 12 vs 24 hour, and sometimes Saturday is "Sa" and sometimes "Sat". That's four "legal" formats right there. Then there are the complicated situations. I once gave up on reporting the closing hours for one attraction because the hours varied significantly not just by the day of the week, but also by the month. Their website dedicated a whole page to their opening hours. WhatamIdoing (talk) 15:52, 22 September 2020 (UTC)
- Nobody said they were sacred, I even said that we might be willing to change them. But this will need to happen across the whole site as a new standard, not be done piecemeal so that we have a bunch of different formats in use.--ThunderingTyphoons! (talk) 12:51, 22 September 2020 (UTC)
- The format of the property seems to be quite flexible, as shown by examples at Wikidata:Property proposal/opening hours, but there might be important special cases where the Wikidata format is more convoluted than the Wikivoyage one. In any case, we need code to get the info we want and format it in some way. Perhaps the result of a well written database query is suitable for us, but I'd try to write that query/code first and look at how more complicated entries get to look like before we deem a Luo module is unnecessary. –LPfi (talk) 12:44, 22 September 2020 (UTC)
- I think it is possible for code to give the relevant outputs based on machine readable data on WD. Hobbitschuster (talk) 12:45, 21 September 2020 (UTC)
- No, that's not true. "Sa" should never be "Sat"; when you see that, please correct it.
- We have two standardised systems in use here, for the 24-hour clock and the 12-hour clock, though these are really just variations of the same system: aside from the times, everything else is the same. The more complicated situations I grant you, but these are a tiny minority.--ThunderingTyphoons! (talk) 16:53, 22 September 2020 (UTC)
- (response to WAID?, 15:44) If I have to correct all the formatting by hand as soon as imported, why would I bother doing that rather than looking up the hours myself online? The idea is to share data seamlessly across the wikis, and presumably Wikidata would also benefit by importing opening hours from Wikivoyage. If we both use the same system(s), this is made easier for everyone involved.--ThunderingTyphoons! (talk) 16:59, 22 September 2020 (UTC)
- Because formatting content is faster that looking up content plus formatting it. WhatamIdoing (talk) 15:49, 23 September 2020 (UTC)
- Thanks NMaia for making this happen! It would be great if the listing editor could be updated to do the matching like it does for other Wikidata fields (it will be a bit more complex, so maybe just the simple cases?) Syced (talk) 00:28, 23 September 2020 (UTC)
- NMaia, if I want to specify "Mon 12:00-14:00 and 19:00-21:00" I suppose that I have to add two different values (one for 12:00-14:00 and one for 19:00-21:00), correct? Or there's a possibility to add both time range under the same value (i.e. Monday)?
- Regarding the timing won't be better to strictly store the time as HH:MM (24h)? This will make it easier to elaborate the output according to any specific need. --Andyrom75 (talk) 09:41, 23 September 2020 (UTC)
- In the proposal, I originally intended to keep them under the same statement, like you mentioned, but someone asked me to change it, so I did. Either way, I think it won't cause many problems for Wikivoyage. NMaia (talk) 11:09, 25 September 2020 (UTC)
- NMaia, it's not a problem but I think it's more complicated to manage the stored information. Having 7 values for the 7 days, each one of them having their own time range I think it would be easier, because that's how generally we show such kind of data.
- What about time syntax? --Andyrom75 (talk) 21:34, 25 September 2020 (UTC)
- In the proposal, I originally intended to keep them under the same statement, like you mentioned, but someone asked me to change it, so I did. Either way, I think it won't cause many problems for Wikivoyage. NMaia (talk) 11:09, 25 September 2020 (UTC)
After the addition of P8626 and P8627 I wrote the Lua module Hours (Q99600452) which makes opening hours, stored at Wikidata, available for establishment listings at the German Wikivoyage. The stand-alone module can be used both with other Lua modules or with an invoke call in a template and can be easily translated. The module produces a compact output with short or abbreviated names and clustered time periods as far as possible which can be learned form the documentation of the module mentioned.
The module is already for productive purposes. There are some maintenance categories to watch the module's operation. A special feature is used which we already added to other Wikidata data-fetching modules in a similar manner: For common ids we are using a table to prevent fetching from Wikidata which is time consuming. --RolandUnger (talk) 08:04, 27 September 2020 (UTC)
New checkin and checkout properties on Wikidata
[edit]Now check-in and check-out times (P8745, P8746) can be entered to Wikidata. For instance {{#property:P8745|from=Q56506795}} will return 14:00, the check-in time of the Nile Ritz-Carlton in Cairo.
The times are stored as an entity id. 2PM (14:00) is stored as Q55811610, and 14:00 is its label. With simple Lua scripts, formatting can be made. Now all listing parameters excluding alt and content can be stored to Wikidata (and displayed at the German Wikivoyage, too). --RolandUnger (talk) 11:30, 24 October 2020 (UTC)
Automatic import from Wikidata not (always) working
[edit]Apologies if this has been asked before.
I've been experimenting with Wikidata imports for attractions in Wikivoyage articles. When I use the listing editor to add a new listing and insert the Wikidata value into the proper field, I see the option to sync fields from Wikidata. Unfortunately this doesn't seem to work consistently. For example with this POI: Q104213978. The Wikidata record contains information for address, opening hours, phone number, and even entrance fee, but none of these are "found" by the listing editor. No matter what I try, the listing editor only seems to be able to retrieve values for website URL, email address, and coordinate location.
Am I doing something wrong? Is anyone else also having trouble automatically retrieving other data fields from Wikidata? Or are these features not implemented yet? —The preceding comment was added by 87.74.129.131 (talk • contribs)
- Sadly the listing editor here at en-wv is only able to fetch data from Wikidata for a few values, but not all. I don't know whether that was a deliberate community decision or just something the volunteers who do the coding have not gotten around to yet. Hobbitschuster (talk) 19:41, 16 December 2020 (UTC)
- In that case I'd much rather spend time on updating/developing the listings editor than on manually copy-pasting data over from Wikidata to Wikivoyage listings -- which would then go out of date pretty quickly anyway. Would you happen to know where the code for the listings editor "lives"? Is this a public repo that accepts pull requests? 87.74.129.131 14:20, 17 December 2020 (UTC)
- Some of the WD fields which are mentioned are fairly new. For example the opening time field was only created on 21 September 2020, and so I doubt that many listings would return useful data. So in this case I would suggesting waiting a few months to let the listing editor catch up. AlasdairW (talk) 22:27, 17 December 2020 (UTC)
The main problem is that several (new) properties are not simple string values, or they are using additional qualifiers. These values cannot be fetched with simple template parser functions. Both the import to the listing template and the listing editor require huge efforts in programming these scripts. Maybe, a complete reprogramming is necessary.
I think that the import of Wikidata data to the listing template should be avoided because the listing template should fetch them directly from Wikidata. Only the data on Wikidata should be updated so they can be used in other Wikivoyage branches, too.
At the German Wikivoyage we made the reprogramming which is now basically finished. The listing/marker package is huge -- really huge, and its programming took four years. Now we are able to fetch almost all useful data from Wikidata (more than 50 properties including their qualifiers) among them opening hours, hotel/restaurant facilities and features, booking.com urls and so on. Some of these parameters like booking.com urls cannot be entered to the listing template at all because they are exclusively fetched from Wikidata.
So, the listing template call can be really short similar like this:
{{listing | name = Alchimistenklause | type = restaurant | wikidata = Q98116402 | auto = y | content = ... }}, or shorter{{listing | wikidata = Q98116402 | auto = y | content = ... }}
At the moment we are testing the usage at the Esperanto Wikivoyage and looking for problems and additional features needed. Within the next weeks we will add the fetching of more Wikidata values and the support of parameter aliases in the listing editor. Then, the listing editor will be able to import all Wikidata values available. Because of the complexity of the Wikidata properties we will not add support to export listing data to Wikidata within the listing editor.
After the addition of some new features to the listing editor we can answer which features are necessary for the listing editor and how to implement them. After this, a reprogramming of the listing editor is necessary: to remove jQuery UI and to add Mediawiki's OOUI (user interfaces), to make the editor available on mobile devices, too. It will take much time. --RolandUnger (talk) 08:00, 18 December 2020 (UTC)
- For some examples of current opportunities, see the examples at de:Module:VCard/Doku. --RolandUnger (talk) 08:15, 18 December 2020 (UTC)
- Wow I'm very impressed by the technical capabilities of the VCard module on de-wv, RolandUnger! I only have limited experience, but what you say makes sense to me: rather than synchronising/importing data fields, dynamically retrieving them from Wikidata ensures they're always up-to-date. It seems logical that business owners would much rather update their information centrally (on Wikidata) once rather than updating every Wikivoyage language article individually. And it makes articles less cluttered by reducing the length of listings, too.
- What's the philosophy behind the "sync" button in the listing editor? With the above in mind, this now feels counterproductive rather than an asset to the project. 87.74.129.131 11:56, 18 December 2020 (UTC)
- sadly de-wv and en-wv have not always cooperated well, owing in part to the history of the fork... For example, en-wv has decided to not link to aggregators such as booking.com As for the decision regarding the "sync" functionality, I think this is to enable easily copying values to wikidata that were input locally as well as choosing deliberately to have certain values different for wd and wv (e.g. Coordinates for the center of a park on wd but the main entrance on wv; the native link on wd but the English language link on en-wv). There may also be aesthetic preferences regarding "clutter" and the fact that the source text of Wikipedia pages can look daunting to first time editors leading to a desire to reduce templates to a minimum. Whether this is a wise decision or was one but no longer is one is a different question. Hobbitschuster (talk) 13:53, 18 December 2020 (UTC)
- Thanks for elaborating on that, I wasn't aware of those subtleties. Looking at the VCard documentation page, de-wv doesn't seem to mind clutter all that much, as evidenced by padding links for Twitter, Youtube and the likes to listings. That seems undesirable to keep articles "clean". However if so much development time and effort has already been invested by our German friends, then it would be silly to not at least try to re-use their work on en-wv as well (instead of developing similar functionality from scratch again). 87.74.129.131 18:50, 18 December 2020 (UTC)
- There are similar rules at Wikivoyage/de as on Wikivoyage/en. We do not make links to booking.com or other aggregators in the article itself. The ids of the aggregators are noted only in data-fields of the wrapping span/div container to get them without an access to Wikidata. But there is another rule for us: The traveler comes first. We like to give all information which is useful to travelers. That's why we added an additional Javascript tool named listing info which shows information for taxi drivers and passerbys to help the traveler. This dialogue can display different information including the aggregators links to a location, too.
- I am not really sure of the real functionality of "sync". But the data at Wikidata are to complex, and sync can handle only strings so it will fail in many cases like hours or phone numbers with comments. That's why the listing editor at Wikivoyage/de will only fetch data from Wikidata to display (usually not to import to the source code) but it will not export data to Wikidata.
- And I do not like to hide an information: if you are fetching data from Wikidata then they do not appear in the original source code. So people who use information from Wikivoyage should not use the simple source code to parse but the expanded source or html code. --RolandUnger (talk) 09:45, 21 December 2020 (UTC)
- It is true, that there is no cooperation between Wikivoyage/de and Wikivoyage/en. But this is not caused by Wikivoyage/de. Our admins and authors helped and help Wikivoyage/en, for instance user:Mey2008 in case of map development, and I gave support at the beginning of Wikimedia-based Wikivoyage, I am helping to administrate English Wikivoyage and I am giving information to the local community. Normally, all that information is ignored. Otherwise I've got a notion that the English community is not interested in ideas developed in other communities and they think only the decisions made the English community is the real deal.
- It is correct that social media services are shown at the German Wikivoyage. But the same is done at the English Wikivoyage using the
urlparameter. The main difference is that social media are marked as social media at the German Wikivoyage but not at the English one. Our scripts are divided into code and localization modules and it is easy to configure local implementations. So, social media can be excluded easily. --RolandUnger (talk) 10:26, 21 December 2020 (UTC)- I would certainly like to coordinate more closely between different Wikivoyages. I'm not very technical, though. Should we have a different thread that enumerates the differences between the Wikivoyages and discusses what we could do to make them more directly compatible with one another? Ikan Kekek (talk) 16:05, 21 December 2020 (UTC)
- I think it is not mainly a problem of compatibility. We at German Wikivoyage try to remain downward compatible with other Wikivoyages. Of course we can discuss/explain the developments at least at the German and Italian Wikivoyages. But it takes time which we should use to improve Wikivoyage. While we at the German Wikivoyage hurrying ahead and making decisions as fast as possible, people at the English Wikivoyage seem not to be interested in or hinder further developments. Programmers at the English Wikivoyage are not really supported by the community, many of them left Wikivoyage or stopped working as a programmer (for instance Mey2008, Ryan/Wrh2). Now, only Andyrom75 from the Italian community is working on scripts. Maybe the English community should discuss first what it really wants to achieve now and in future.
- I was also really surprised on the (missing) reaction of the English community when user NMaia announced the establishment of the Wikidata hours property. He made a good job at Wikidata and now at the Esperanto Wikivoyage. And he thought that he would get support by the English community in that case (only I supported him). But this community was indifferent towards his announcement. --RolandUnger (talk) 15:29, 22 December 2020 (UTC)
- I thought I remembered a number of us being interested. I was. Ikan Kekek (talk) 20:50, 22 December 2020 (UTC)
- Yep. Roland, what interest were we supposed to show other than thanking Nmaia, asking questions, and raising concerns (which is what happened)? When and where has English Wikivoyage hindered developments by other language versions of WV?--ThunderingTyphoons! (talk) 23:30, 22 December 2020 (UTC)
- I commented at Wikidata:Property talk:P8626, but didn't get an feedback on how this works if different days have different opening times. AlasdairW (talk) 23:48, 22 December 2020 (UTC)
- Yep. Roland, what interest were we supposed to show other than thanking Nmaia, asking questions, and raising concerns (which is what happened)? When and where has English Wikivoyage hindered developments by other language versions of WV?--ThunderingTyphoons! (talk) 23:30, 22 December 2020 (UTC)
- I thought I remembered a number of us being interested. I was. Ikan Kekek (talk) 20:50, 22 December 2020 (UTC)
- I would certainly like to coordinate more closely between different Wikivoyages. I'm not very technical, though. Should we have a different thread that enumerates the differences between the Wikivoyages and discusses what we could do to make them more directly compatible with one another? Ikan Kekek (talk) 16:05, 21 December 2020 (UTC)
- Thanks for elaborating on that, I wasn't aware of those subtleties. Looking at the VCard documentation page, de-wv doesn't seem to mind clutter all that much, as evidenced by padding links for Twitter, Youtube and the likes to listings. That seems undesirable to keep articles "clean". However if so much development time and effort has already been invested by our German friends, then it would be silly to not at least try to re-use their work on en-wv as well (instead of developing similar functionality from scratch again). 87.74.129.131 18:50, 18 December 2020 (UTC)
- sadly de-wv and en-wv have not always cooperated well, owing in part to the history of the fork... For example, en-wv has decided to not link to aggregators such as booking.com As for the decision regarding the "sync" functionality, I think this is to enable easily copying values to wikidata that were input locally as well as choosing deliberately to have certain values different for wd and wv (e.g. Coordinates for the center of a park on wd but the main entrance on wv; the native link on wd but the English language link on en-wv). There may also be aesthetic preferences regarding "clutter" and the fact that the source text of Wikipedia pages can look daunting to first time editors leading to a desire to reduce templates to a minimum. Whether this is a wise decision or was one but no longer is one is a different question. Hobbitschuster (talk) 13:53, 18 December 2020 (UTC)
What is the point of adding Wikidata to individual listings
[edit]Why would anyone (who doesn't edit) want to click it on. An example of one can be found here (Bhandra Fort) Tai123.123 (talk) 05:44, 2 November 2021 (UTC)
- It's mainly for doing a quick fetch of data available. SHB2000 (talk | contribs | meta.wikimedia) 06:40, 2 November 2021 (UTC)
- I think that's fine to do, but what about a Wikidata infobox? I say no, no way, and I will revert that edit. Ikan Kekek (talk) 07:58, 2 November 2021 (UTC)
- Ditto as well. No Wikidata infoboxes please. That template doesn't even work properly. SHB2000 (talk | contribs | meta.wikimedia) 08:04, 2 November 2021 (UTC)
- I think that's fine to do, but what about a Wikidata infobox? I say no, no way, and I will revert that edit. Ikan Kekek (talk) 07:58, 2 November 2021 (UTC)
- The Wikidata page itself is probably just confusing for most users, but in addition to automatically add e.g. coordinates and the Wikipedia link as soon as an article is written (and that article is useful for many), some readers may use it to find a Wikipedia article in some other language when there is none in English. For editors the icon avoids the need to manually copy use the id to construct the address (and not all editors would do that routinely). –LPfi (talk) 09:12, 2 November 2021 (UTC)
- Ok thank you, I didn’t realize it automatically added the Wikipedia page (I thought they had to be added in the wikipedia section). I will probably stick to manually adding coords and Wikipedia as I don’t feel the Wikidata button is useful. Tai123.123 (talk) 14:37, 2 November 2021 (UTC)
- If you add coords, and a Wikidata item, then you can send your coords to Wikidata, which helps all the other Wikivoyages that might link to that location. WhatamIdoing (talk) 16:27, 2 November 2021 (UTC)
- It might also be useful for WP articles too, although I'm not too sure on how that works. SHB2000 (talk | contribs | meta.wikimedia) 05:43, 10 November 2021 (UTC)
- That kind of information will be used automagically by some Wikipedias, including Russian and Spanish (assuming there is an article for the attraction), but not by the English Wikipedia. WhatamIdoing (talk) 17:05, 10 November 2021 (UTC)
- It might also be useful for WP articles too, although I'm not too sure on how that works. SHB2000 (talk | contribs | meta.wikimedia) 05:43, 10 November 2021 (UTC)
- If you add coords, and a Wikidata item, then you can send your coords to Wikidata, which helps all the other Wikivoyages that might link to that location. WhatamIdoing (talk) 16:27, 2 November 2021 (UTC)
- Ok thank you, I didn’t realize it automatically added the Wikipedia page (I thought they had to be added in the wikipedia section). I will probably stick to manually adding coords and Wikipedia as I don’t feel the Wikidata button is useful. Tai123.123 (talk) 14:37, 2 November 2021 (UTC)
- The Wikidata page itself is probably just confusing for most users, but in addition to automatically add e.g. coordinates and the Wikipedia link as soon as an article is written (and that article is useful for many), some readers may use it to find a Wikipedia article in some other language when there is none in English. For editors the icon avoids the need to manually copy use the id to construct the address (and not all editors would do that routinely). –LPfi (talk) 09:12, 2 November 2021 (UTC)
(not) a policy document?
[edit]Top of the page has notice: This page is an incubator for ideas on how to work with Wikidata. This is not a policy document....and I wonder if there are policy documents that are fixed and should be linked here? --Zblace (talk) 09:00, 21 January 2022 (UTC)
'Wikidata item' link is moving. Find out where...
[edit]{{}}
Hello everyone, a small change will soon be coming to the user-interface of your Wikimedia project.
The Wikidata item sitelink currently found under the General section of the Tools sidebar menu will move into the In Other Projects section.
We would like the Wiki communities feedback so please let us know or ask questions on the Discussion page before we enable the change which can take place October 4 2024, circa 15:00 UTC+2.
More information can be found on the project page.
We welcome your feedback and questions.
MediaWiki message delivery (talk) 18:57, 27 September 2024 (UTC)
- Danny Benjafield (WMDE), thanks for this note. This site still uses the old Vector skin. There are currently two links in the sidebar:
- "Tools": Wikidata item to d:Special:EntityPage/Q16503
- "In other projects": Wikidata to d:Wikidata:Project chat
- Will both of those links now be in the same section, or is the plan to remove one of those links? WhatamIdoing (talk) 19:49, 27 September 2024 (UTC)
- There hasn't been any link to the wikidata item in "in other projects" on most pages. Project pages are special in that there may be an equivalent on Wikidata, in addition to the item page.
- I think "in other projects" for this page should link to the Wikidata project chat, but according to Wikidata policies (cf Commons categories), I assume it will link to the item, unless we get two Wikidata entries in that section.
- –LPfi (talk) 09:40, 28 September 2024 (UTC)
- I think there should be two links on nearly all pages in the mainspace, as well as many templates and help pages. WhatamIdoing (talk) 19:40, 28 September 2024 (UTC)
- Hello @WhatamIdoing, both of those links will move into the new section (In Other Projects). A ticket on this topic can be found on our workboard (Phabricator: T372566) and we will be investigating if any further work to differentiate those 2 links is required. -Danny Benjafield (WMDE) (talk) 12:46, 30 September 2024 (UTC)
- That sounds okay to me. As long as we've got both links available, I think we'll learn which one does the thing we need. WhatamIdoing (talk) 16:35, 30 September 2024 (UTC)
Wikidata and Sister Projects: Online event
[edit]Hello everyone, I’m writing to announce an upcoming event called Wikidata and Sister Projects that will be a mini online conference to highlight the different ways Wikidata can be connected and integrated with the other WM projects.
We are currently looking for session ideas and speakers for our program and wanted to reach out in case there were any editors here that might have a cool idea for a session proposal. Sessions can be found on the event discussion page. As previously mentioned, we would like to showcase the relationship between Wikivoyage and Wikidata and how data such from listings/VCards is a collaborative effort between the 2 projects, or how structured data aids in geoshape and map creation.
The event is scheduled between May 29 - June 1st, 2025. If you have any questions about the event, would like more information or have a session idea to propose, please feel free to get in touch by replying to this post or writing on the event page or on my talk page. Thanks for reading, - Danny Benjafield (WMDE) (talk) 07:19, 1 April 2025 (UTC)
- @Danny Benjafield (WMDE) Is it still possible to propose session? It says proposals need to be submitted by March 31, yet your announcement here was made on April 1. I am planning to submit a lightning talk about linking tourist points of interest and pictures to Wikidata. OhanaUnitedTalk page 14:41, 2 April 2025 (UTC)
- Hello @OhanaUnited, it is still possible (and warmly received) to submit a session idea, I updated the pages with a new deadline. Looking forwards to your proposal! Thank you, - Danny Benjafield (WMDE) (talk) 15:46, 2 April 2025 (UTC)
- Done! I have submitted. OhanaUnitedTalk page 19:50, 2 April 2025 (UTC)
- Hello @OhanaUnited, it is still possible (and warmly received) to submit a session idea, I updated the pages with a new deadline. Looking forwards to your proposal! Thank you, - Danny Benjafield (WMDE) (talk) 15:46, 2 April 2025 (UTC)