<div dir="ltr">Joseph, could you clarify what you mean by "Map Features entry" ?  If you only refer to keys/tags/relations/relation roles, than those things are automatically created -- an editor only needs to translate them.<div><br></div><div>I do agree that if we want to store more diverse data items, we need specialized UI, at least for the initial item creation. Luckily, there is a large Wikidata community that has already done many such custom UIs. For example, Wikidata now stores language data (all lexems), and there is a community-created tool to add such words -- <a href="https://tools.wmflabs.org/lexeme-forms/">https://tools.wmflabs.org/lexeme-forms/</a>  (I'm not sure if this tool checks for duplicates, please check first if you want to add new data). There are many other tools we can model after.  Best thing -- those tools don't have to be part of the wiki, but can reside anywhere else, and could be in pure client-side JavaScript.</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Sun, Aug 4, 2019 at 2:05 AM Joseph Eisenberg <<a href="mailto:joseph.eisenberg@gmail.com">joseph.eisenberg@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">So far, I've found it very difficult to create and edit new wikibase<br>
entries. I don't think it will be easier for Indonesian mappers to<br>
create a wikibase entry for every Map Features entry, rather than<br>
creating a stub page with a description.<br>
<br>
The advantage of translating wiki pages for each features is that then<br>
there is a human-readable page which can be updated and expanded over<br>
time, and also it's clear where the list of feature descriptions are<br>
coming from.<br>
<br>
If you want everyone to create wikibase entries instead, there needs<br>
to be a much easier, friendlier interface, available in all languages,<br>
and I think such a major change should be discussed and be implemented<br>
only if there is consensus that this would be a clear improvement for<br>
most language communities.<br>
<br>
On 8/4/19, Yuri Astrakhan <<a href="mailto:yuriastrakhan@gmail.com" target="_blank">yuriastrakhan@gmail.com</a>> wrote:<br>
> The biggest issue with using Lua/Server side scripting with large lists is<br>
> that every single data item used on a wiki page requires a separate SQL<br>
> query (or even multiple ones), due to how mediawiki + wikibase is<br>
> implemented.  On the other hand, relying on TagInfo has some shortcomings -<br>
> TagInfo does not (yet) understand data items, relying on its own wiki page<br>
> parser, it is very fixed in a way it can present information, and every<br>
> wiki page view also uses makes 1 or more external call to taginfo (higher<br>
> chance of something going down).<br>
><br>
> There is a popular middle ground that can solve it for us -- very flexible,<br>
> highly performant, uses a common data source (data items), and relies on a<br>
> single system.  Essentially it is a bot-updated wiki markup:<br>
><br>
> * an editor adds a special template at the top of a wiki page, where they<br>
> specify a SPARQL query for the data they want - i.e. "find all<br>
> label+description+image of data items, whose type is a 'tag' and whose key<br>
> is 'denomination'".  A bot would run that query on occasion (e.g. once a<br>
> day), and append query results to that same page after the template.  Thus,<br>
> the result becomes a regular wiki markup, without any significant server<br>
> costs.  See <a href="https://www.wikidata.org/wiki/Template:Wikidata_list" rel="noreferrer" target="_blank">https://www.wikidata.org/wiki/Template:Wikidata_list</a><br>
><br>
> The PROs:<br>
> * The bot can run at any moment, by anyone, to update the data<br>
> * In the worst case of a bot completely dying, wiki markup could be edited<br>
> by hand until the bot is fixed<br>
> * very flexible - a complex query could get any data needed for the output,<br>
> and the output is templated to show in any kind of a list/table format.<br>
><br>
> CONs:<br>
> * every list update is essentially a wiki page edit, slowly increasing<br>
> history. This is not that big of a deal because size wise the growth is<br>
> small and has very little performance impact, plus it makes it possible to<br>
> track changes with time.<br>
><br>
> On Sat, Aug 3, 2019 at 5:25 PM Andrew Hain <<a href="mailto:andrewhainosm@hotmail.co.uk" target="_blank">andrewhainosm@hotmail.co.uk</a>><br>
> wrote:<br>
><br>
>> Now the wiki has data items and scripting in Lua I have been wondering<br>
>> whether they are a useful alternative to Taginfo-driven lists.<br>
>><br>
>> Advantages of server scripts:<br>
>><br>
>>    1. Descriptions can be generated from data items, tharefore they can<br>
>>    be in a language where there is no long form documentation for the<br>
>> key.<br>
>>    This resolves the issues that have limited use of taglists in<br>
>> languages<br>
>>    other than English because descriptions can be rolled out quickly and<br>
>> some<br>
>>    can be copied from the old map features templates.<br>
>>    2. Tables at the top of pages are visible immediately,<br>
>>    3. A successful connection to <a href="http://tagindo.openstreetmap.org" rel="noreferrer" target="_blank">tagindo.openstreetmap.org</a> is<br>
>> unnecessary.<br>
>><br>
>> Advantages of taglists driven by Taginfo:<br>
>><br>
>>    1. The technology aleady exists and can be rolled out.<br>
>>    2. Separate scripts avoid overloading the server (Map Features in<br>
>>    Polish, Ukrainian and Japanese hits wiki limits).<br>
>>    3. The web scripts are free-standing and can be hosted on another<br>
>>    website outside the wiki,<br>
>><br>
>> (crossposted from<br>
>> <a href="https://wiki.openstreetmap.org/wiki/Talk:Taginfo/Taglists#Server_scripts_as_alternative_taglists" rel="noreferrer" target="_blank">https://wiki.openstreetmap.org/wiki/Talk:Taginfo/Taglists#Server_scripts_as_alternative_taglists</a><br>
>> )<br>
>><br>
>> --<br>
>> Andrew<br>
>> Talk:Taginfo/Taglists - OpenStreetMap Wiki<br>
>> <<a href="https://wiki.openstreetmap.org/wiki/Talk:Taginfo/Taglists#Server_scripts_as_alternative_taglists" rel="noreferrer" target="_blank">https://wiki.openstreetmap.org/wiki/Talk:Taginfo/Taglists#Server_scripts_as_alternative_taglists</a>><br>
>> Languages. This is a very cool feature! One question: Could the template<br>
>> get the langugage automatically? I know this is done on some templates<br>
>> (e.g. Template:Tag).-- Jojo4u 17:20, 20 August 2015 (UTC) . I am not a<br>
>> template wizard.<br>
>> <a href="http://wiki.openstreetmap.org" rel="noreferrer" target="_blank">wiki.openstreetmap.org</a><br>
>><br>
>> ------------------------------<br>
>> *From:* Joseph Eisenberg <<a href="mailto:joseph.eisenberg@gmail.com" target="_blank">joseph.eisenberg@gmail.com</a>><br>
>> *Sent:* 02 August 2019 14:22<br>
>> *To:* Tag discussion, strategy and related tools <<br>
>> <a href="mailto:tagging@openstreetmap.org" target="_blank">tagging@openstreetmap.org</a>><br>
>> *Subject:* Re: [Tagging] Rethinking Map Features<br>
>><br>
>> Andrew,<br>
>><br>
>> I now think it is a good idea to switch to taglists for all of the Map<br>
>> Feature page templates. It will make it much easier to keep the pages<br>
>> consistent and to a reasonable length if all of the descriptions are<br>
>> pulled from the wiki pages directly (just as is done for descriptions<br>
>> used by Taginfo).<br>
>><br>
>> This just means that any deprecated or discouraged tags which are<br>
>> currently "strikethrough" on Map Features will need something in the<br>
>> description that mentions that they are discouraged. This is a good<br>
>> idea anyway, so that the documentation is consistent.<br>
>><br>
>> Joseph<br>
>><br>
>> On 7/7/19, Andrew Hain <<a href="mailto:andrewhainosm@hotmail.co.uk" target="_blank">andrewhainosm@hotmail.co.uk</a>> wrote:<br>
>> > I have been working on a scheme to improve the cross-language quality<br>
>> > of<br>
>> Map<br>
>> > Features.<br>
>> > [<br>
>> <a href="https://wiki.openstreetmap.org/wiki/Talk:Map_Features#Reimagining_Map_Features" rel="noreferrer" target="_blank">https://wiki.openstreetmap.org/wiki/Talk:Map_Features#Reimagining_Map_Features</a><br>
>> ]<br>
>> ><br>
>> > Of course the page may deserve a bigger or deeper rethink.<br>
>> ><br>
>> > --<br>
>> > Andrew<br>
>> > Talk:Map Features - OpenStreetMap<br>
>> > Wiki<<br>
>> <a href="https://wiki.openstreetmap.org/wiki/Talk:Map_Features#Reimagining_Map_Features" rel="noreferrer" target="_blank">https://wiki.openstreetmap.org/wiki/Talk:Map_Features#Reimagining_Map_Features</a><br>
>> ><br>
>> > amenity=school rendering colour. amenity=school is displayed in the<br>
>> > page<br>
>> as<br>
>> > a light-purple area for ways, whereas mapnik renders them as a pale<br>
>> yellow<br>
>> > colour<br>
>> > <a href="http://wiki.openstreetmap.org" rel="noreferrer" target="_blank">wiki.openstreetmap.org</a><br>
>> ><br>
>> ><br>
>><br>
>> _______________________________________________<br>
>> Tagging mailing list<br>
>> <a href="mailto:Tagging@openstreetmap.org" target="_blank">Tagging@openstreetmap.org</a><br>
>> <a href="https://lists.openstreetmap.org/listinfo/tagging" rel="noreferrer" target="_blank">https://lists.openstreetmap.org/listinfo/tagging</a><br>
>> _______________________________________________<br>
>> Tagging mailing list<br>
>> <a href="mailto:Tagging@openstreetmap.org" target="_blank">Tagging@openstreetmap.org</a><br>
>> <a href="https://lists.openstreetmap.org/listinfo/tagging" rel="noreferrer" target="_blank">https://lists.openstreetmap.org/listinfo/tagging</a><br>
>><br>
><br>
<br>
_______________________________________________<br>
Tagging mailing list<br>
<a href="mailto:Tagging@openstreetmap.org" target="_blank">Tagging@openstreetmap.org</a><br>
<a href="https://lists.openstreetmap.org/listinfo/tagging" rel="noreferrer" target="_blank">https://lists.openstreetmap.org/listinfo/tagging</a><br>
</blockquote></div>