[Wikitech-l] Discovery Weekly Update for the week starting 2016-12-19 ⛄️

[Chris Koerner]

Season's Greetings,
A few updates from the Discovery department this week.

This is the last weekly update from the Discovery department for the year.
We'll be skipping next week due to the holiday's and will see you all in
January with a fresh 2017 edition.

== Highlights ==
* Secondary result functionality will be available over the search API in
early January! Currently, this allows consumers of the search API to
benefit from automated language detection [[TextCat]] and forwarding of
search queries. [0] [1]

== Discussions ==

=== Search ===
* Secondary result functionality will be available over the search API in
early January! Currently, this allows consumers of the search API to
benefit from automated language detection [[TextCat]] and forwarding of
search queries. [0] [1]
* Corrected an error on Hebrew wikis where searches without diacritics
could sometimes not find appropriate results that contained diacritics. [3]


Feedback and suggestions on this weekly update are welcome.

[0] https://www.mediawiki.org/wiki/TextCat
[1] https://phabricator.wikimedia.org/T142795
[3] https://phabricator.wikimedia.org/T3836


The full update, and archive of all past updates, can be found on
MediaWiki.org:

https://www.mediawiki.org/wiki/Discovery/Status_updates

Interested in getting involved? See tasks marked as "Easy" or "Volunteer
needed" in Phabricator.

[1] https://phabricator.wikimedia.org/maniphest/query/qW51XhCCd8.7/#R
[2] https://phabricator.wikimedia.org/maniphest/query/5KEPuEJh9TPS/#R


Yours,
Chris Koerner
Community Liaison - Discovery
Wikimedia Foundation
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

[Wikitech-l] Correction on Structured Data on Commons project

[Katie Horn]

Hello all,

Yesterday, an announcement (Now live: Shared structured data), incorrectly
stated that Structured Data had been launched on Commons.

The feature which was inaccurately named “Structured Data”, enables users
to add tabular data to the data namespace on Commons via the regular page
editor and to further display and/or visualize that data from other wikis.
This work is unrelated to an ongoing project called Structured Data on
Commons. For more on the newly launched feature, see the Tabular Data [1]
and Map Data [2] help pages on MediaWiki.org.

For information on the Structured Data on Commons project, designed to
associate structured data with media files on Commons to improve their
discoverability, please visit the project page on Commons. [3]

Thank you,

-Katie

[1] - https://www.mediawiki.org/wiki/Help:Tabular_Data

[2] - https://www.mediawiki.org/wiki/Help:Map_Data
[3] - https://commons.wikimedia.org/wiki/Commons:Structured_data
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] [Mediawiki-i18n] Offering internationalized programming facilities within WM enviroment

[C. Scott Ananian]

I think it is easier to create a new localizable programming environment
from scratch, than to try to localize existing tools and APIs.

For example, block-based programming languages (like Scratch and eToys)
tend to be fairly easy to translate -- there are some issues regarding
fixed size labels, the meaning of concatenating labels in various
langauges, etc, but these programs proved surmountable.  We used these
extensively at One Laptop per Child.

At OLPC I worked on a block-based JavaScript-subset, which allowed complete
translation between "text based" and "block based" views of the code:
http://turtlescript.github.cscott.net/
You could localize the labels in the block-based version and still "compile
down" to the legacy/English APIs.

As some folks know I've been a persistent advocate for JavaScript in
Scribunto, and I've contributed to v8js to this end.

Another option is to move away from textual scripting languages on wiki
entirely.  For example, https://phabricator.wikimedia.org/T114454 proposes
using Visual Editor to perform more of the "template" tasks, with a
stronger separation of code, "layout", and data.  Template edits which
affect the visual presentation or the data ("arguments") but not the
underlying code should be possible in Visual Editor in a fully localized
manner.  The textual "code" portion would be de-emphasized for most tasks.
For tasks which do require "code" to be written, you'd use one of the
techniques described above.
  --scott
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Offering internationalized programming facilities within WM enviroment

[mathieu stumpf guntz]

Le 22/12/2016 à 19:30, Chad a écrit :

On Thu, Dec 22, 2016 at 10:42 AM mathieu stumpf guntz <
psychosl...@culture-libre.org> wrote:


* mediawiki.util get renamed to mediawiki.outil : there is no problem
with that, isn't it?
* then changed to alors : there is no problem with that, isn't it?



Yes, that is a problem. As pointed out by others: it makes grepping for
code when doing refactoring basically impossible as I'd have to know
a list of every possible translation of "util." That's not a good use of
developer time at all.
Well, then I would say that it's more like a projection of a useful tool 
for a given situation on an other situation, however  similar, where it 
is no longer that useful. What you want isn't find the lexem (or even 
any accidentally matching string), but the seme (or semene). In most 
programming languages there is probably a strong enough correlation 
between lexem and seme(ne) is strong enough to make a simple regular 
expression matching useful in many cases. But even their, a grep 
approach can quickly show its limits (especially with false positive in 
my experience). Having a tool which let you perform transformations 
based on an AST is often far more accurate and flexible.



I mean these ideas have merit on the face of them, but I'm totally in the
"this is nice but probably not worth the maintenance burden" camp along
with Gergo.
Well, I do understand the argumentation, and it does sounds reasonable 
to me. It's more like I wouldn't place the cursor of maintenance burden 
tolerance at the same point, especially when I feel it might have large 
impact on (language) diversity.


Also, my understanding is that the main concern here is about letting 
developers with advanced skills easily go and help in misc. wiki. And as 
I understand it, this shouldn't be such a big deal with a central 
repository where most common problematic are (hopefully) already 
factored in a way which ease maintenance. To my mind, it's compatible 
with having more local specific problem solved, and possibly some local 
wrapper of centralized code, in a way which please the local community 
(which might just as well prefer not to use code localization after all).



T150417 was declined, and for good reasons I think.

Well, as said, I'm not in fundamental disagreement with that.

I think ideas like Babylscript are more useful for a project where you've
got a lot of developers in a *single* non-English language. For example,
a team of Italians who would rather work in Italian than English. In our
case, we've got *many* languages and being able to use things across
wikis/languages is important.
To my mind, having a lot of developers with many languages doesn't 
exclude that we also have developers in a single non-English language as 
part of the former, does it?




-Chad
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l



___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] [Maps-l] Now live: Shared structured data

[Susanna Ånäs]

Great work!

I'm happy with the new naming, Commons Datasets.

For historical maps we have been waiting to have a way to store data about
the rectification with the map image. Here it is! It brings us one notch
closer to being able to work with zoomable historical maps in Wikipedia.

Some have noted that the datasets are contrary to what Wikidata is about.
Instead, they are complementary! Not all data is either suitable for
Wikidata or licensed openly enough. Or not yet. Many great datasets can be
introduced to the Wikimedia online communities. The data owners will pay
attention to more open licensing, seeing their data being used. The
wikidatans will pick up interesting datasets and work to prepare missing
properties for them in Wikidata and ignite their bots. Sometimes the data
can just be used as is.

This is one part of the puzzle and it will be interesting to see how the
pieces fall into their places and evolve further.

In the coming few days there'll be time to digest and experiment.

Happy holidays
Susanna

2016-12-23 5:22 GMT+02:00 Bohdan Melnychuk :

> Yay :)
>
> As someone who already has plans to actively use it in both my metapedian
> role (e.g. CEE Spring article writing contest statistics data for building
> Graphs from being stored like https://meta.wikimedia.org/w/
> index.php?title=User:BaseBot/CEES/MMXVI/Per_country_sums_(
> general)=edit
> 
> to a better format of https://commons.wikimedia.org/
> wiki/Data:Wikimedia/CEE_Spring/Statistics/MMXVI/Per_
> country_sums_(general).tab which can be turned by Lua to the same output
> but now with it being controlled on wiki rather than bot code part) and
> exopedianish for actual articles I think it is wonderful.
>
> I do think that it needs tight cross linking with Wikidata and perfectly a
> way to run queries against both the sources at the same time (e.g. "give me
> the weather in all the current capitals in the date the comet Whatever was
> closest to the Sun the last time" or whatever else more useful thing may
> come into one's mind), but that does not deny the fact that it is very
> useful already.
>
> It can also be used as an intermediate location for data on the way to be
> imported to Wikidata, IMHO.
>
> --Base
>
>
> 22.12.2016, 21:31, "Yuri Astrakhan" :
>
> Gift season! We have launched structured data on Commons, available from
> all wikis.
>
> TLDR; One data store. Use everywhere. Upload table data to Commons, with
> localization, and use it to create wiki tables, lists, or use directly in
> graphs. Works for GeoJSON maps too. Must be licensed as CC0. Try this
> per-state GDP map demo, and select multiple years. More demos at the bottom.
> US Map state highlight
> 
>
> Data can now be stored as *.tab and *.map pages in the data namespace on
> Commons. That data may contain localization, so a table cell could be in
> multiple languages. And that data is accessible from any wikis, by Lua
> scripts, Graphs, and Maps.
>
> Lua lets you generate wiki tables from the data by filtering, converting,
> mixing, and formatting the raw data. Lua also lets you generate lists. Or
> any wiki markup.
>
> Graphs can use both .tab and .map directly to visualize the data and let
> users interact with it. The GDP demo above uses a map from Commons, and
> colors each segment with the data based on a data table.
>
> Kartographer (/) can use the .map data as an extra
> layer on top of the base map. This way we can show endangered species'
> habitat.
>
> == Demo ==
> * Raw data example
> 
> * Interactive Weather data
> 
> * Same data in Weather template
> 
> * Interactive GDP map
> 
> * Endangered Jemez Mountains salamander - habitat
> 
> * Population history
> 
> * Line chart 
>
> == Getting started ==
> * Try creating a page at data:Sandbox/.tab on Commons. Don't forget
> the .tab extension, or it won't work.
> * Try using some data with the Line chart graph template
> A thorough guide is needed, help is welcome!
>
> == Documentation links ==
> * Tabular help 
> * Map help 
> If you find a bug, create Phabricator ticket with #tabular-data tag, or
> comment on the documentation talk pages.
>
> == FAQ ==
> * Relation to Wikidata:  Wikidata is about "facts" (small pieces of
> information). Structured data is