jeblad added a comment.
Will you use the same form when measuring the distance to the sea as the distance to a mountain? (I know, it is a trick question.)
Yeah, Daniels proposal could work for most of the cases.TASK DETAILhttps://phabricator.wikimedia.org/T86528EMAIL
Nemo_bis added a comment.
In T86528#2510135, @Smalyshev wrote:
And CLDR templates on that page you quoted do not cover that. They have long-few and long-many, but how many is few and how many is many?
CLDR is certainly hard when you first look at it, but "few" and "many" have a specific
jeblad added a comment.
This will not cover most of world languages in any adequate quality anytime soon. Researchers are spending years to build morphological engines which are far from perfect. Regular expressions are not a tool that allows creating such complex systems (but finite state
Nikerabbit added a comment.
Sorry for going off topic, feel free to skip:
In T86528#2504269, @Amire80 wrote:
Of course it's not only for names of languages. Names of languages is just a first step. The same format can be used for any word, including names units.
Actually, no. It's not
Amire80 added a comment.
Of course it's not only for names of languages. Names of languages is just a first step. The same format can be used for any word, including names units.
Yes, it's possible that regular expressions won't cut it for some words or some languages, but if this can be done in
Smalyshev added a comment.
T115217 looks interesting but it covers only a small subset of the grammar rules - namely, ones that are needed to name the languages, most of which follow small number of patterns. If we want names of units - which, in our case, may be names of virtually any objects -
Nemo_bis added a comment.
I mean, if you desire to keep the units on the wiki you could for instance add a parser function for value and unit rendering to the CLDR extension (and allow using wikitext in labels or whatever). There are many templates to handle this rather tedious task, so it would
Nemo_bis added a comment.
Why a bot? We import CLDR data in the code, usually. Mostly with the cldr extension.TASK DETAILhttps://phabricator.wikimedia.org/T86528EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: Nemo_bisCc: Nemo_bis, hoo, mxn, Snipre,
Smalyshev added a comment.
Maybe worth trying to get a bot that would import at least the obvious cases from CLDR?TASK DETAILhttps://phabricator.wikimedia.org/T86528EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: SmalyshevCc: Nemo_bis, hoo, mxn, Snipre,
Nemo_bis added a comment.
I'm not sure how many units this is supposed to cover, but CLDR provides localisation for units: http://www.unicode.org/cldr/charts/latest/by_type/index.html (Measurement Systems | Duration | Length | Area | Volume | Speed and Acceleration | Mass and Weight | Energy and
JanZerebecki added a comment.
Btw. there are already special items configured in:
$wgWBClientSettings['badgeClassNames']
TASK DETAIL
https://phabricator.wikimedia.org/T86528
REPLY HANDLER ACTIONS
Reply to comment or attach files, or !close, !claim, !unsubscribe or !assign
username.
adrianheine added a comment.
@JanZerebecki If you just want to `printf` an URL from a string value, there's
not much to it. However, there's so much more we can do: validate the input,
provide specific input methods, add a preview to the output (for example for
commons images), …
TASK DETAIL
JanZerebecki added a comment.
@adrianheine All there examples are not specific to Wikidata but would work
differently for different targets (no matter if the statement is on Wikidata or
somewhere else) and for the same target like e.g. Commons it would be nice to
have it work even on Wikibase
JanZerebecki added a comment.
In https://phabricator.wikimedia.org/T86528#970857, @Snaterlicious wrote:
Will we please convert label, description and aliases to statements then?
Yes, good idea. Although that would be a quite involved change, so it is not
likely. Converting site links to
JanZerebecki added a comment.
In https://phabricator.wikimedia.org/T86528#975324, @adrianheine wrote:
For example, we would not have to implement AuthorityControl in WikibaseRepo,
instead, we could Wikibase flexible enough to allow Wikidata to implement
AuthorityControl in a sane way in PHP
adrianheine added a comment.
I know I made this point several times, but I haven't seen it addressed or
debunked yet, so I'll continue to do so:
I think we limit ourselves by not allowing us to write PHP code specific for
Wikidata. I think we make Wikibase worse by doing so. I think, by doing
Snaterlicious added a comment.
I my opinion, specifically developing for Wikidata would be opening Pandora's
box. We already have rather awkward Wikidata-specifics in the the code
(Calendar types reference Wikidata items, for example) and, from my point of
view, dealing with gadgets is already
Smalyshev added a comment.
The idea of localized units is great, however I wonder about the following
things. Let's say we express quantities in all kinds of different units, so if
we have a property for the area of the country, one country would have it in
square meters, another in square
JanZerebecki added a comment.
Also, we would have to base this functionality on a user defined property,
which seems a bit brittle.
How is that more brittle than having units as items?
TASK DETAIL
https://phabricator.wikimedia.org/T86528
REPLY HANDLER ACTIONS
Reply to comment or
Snaterlicious added a comment.
Just some thoughts on that:
In my opinion, the full name should be defined by a property as well. Using
the label would add an an assumption on top of the concept of label whose
original purpose is nothing more than to identify an entity. Additionally, if
there
20 matches
Mail list logo
