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