Lucas_Werkmeister_WMDE added a comment.
Note that this demonstrates the problem Thiemo mentioned in T95553#3916063: we currently can’t parse «9e siècle».TASK DETAILhttps://phabricator.wikimedia.org/T95553EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To:
Ayack added a comment.
In T95553#4941337, @VIGNERON wrote:
Did someone did something?
At least in French, we now have nice "9e siècle" but not in English or Breton :(
I don't know if you're talking about that, but I changed translations some times ago on TranslateWiki. See
VIGNERON added a comment.
Did someone did something?
At least in French, we now have nice "9e siècle" but not in English or Breton :(TASK DETAILhttps://phabricator.wikimedia.org/T95553EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: VIGNERONCc: Nikki,
kaldari added a comment.
the word "century" is not compatible with the data model and should not be used anywhere in the user interface.
@Jc3s5h: As I've mentioned before, there are separate tickets for discussing both the century data model problem (T73459) and the use of "century" in the
Jc3s5h added a comment.
In T95553#4430944, @Jarekt wrote:
Phabricator tickets are not a good place to debate the definitions of phrases like "20th century". The meaning of that term was defined a long time ago and should not depend on Wikidata or other software. I am no expert on the matter but
Jc3s5h added a comment.
I would say the data model must be obeyed, and every aspect of the user interface must obey the data model. The presence of the word "century" in the user interface is a lie. This ticket should be closed as requesting the developers to refine a lie.TASK
Jc86035 added a comment.
user interface is the only place that interprets the precision
Is the standard behaviour documented anywhere? Wikibase/DataModel does not appear to contain any information about how the behaviour of the user interface is different for centuries and millennia.TASK
Lucas_Werkmeister_WMDE added a comment.
In T95553#4430887, @Jc3s5h wrote:
I would say rather that most of Wikibase follows much of ISO 8601:2004, and in particular, follows that standard with respect to centuries, for example, when 4 digit years are being used, the precision is century, and the
Jc86035 added a comment.
when 4 digit years are being used, the precision is century, and the first two digits of the year are 20, then the date could be anywhere from 1 January 2000 to and including 31 December 2099
@Jc3s5h The user interface says "20. century" for +2000-00-00T00:00:00/7, and if
Jarekt added a comment.
Phabricator tickets are not a good place to debate the definitions of phrases like "20th century". The meaning of that term was defined a long time ago and should not depend on Wikidata or other software. I am no expert on the matter but articles on individual centuries on
Jc3s5h added a comment.
In T95553#4430864, @Jc86035 wrote:
(My earlier description edits were incorrect and were based on a bad interpretation of the project chat discussion with complaints about external tools. The thing that causes the issue is that some software doesn't realize that Wikibase
Jc86035 added a comment.
(My earlier description edits were incorrect and were based on a bad interpretation of the project chat discussion with complaints about external tools. The thing that causes the issue is that some software doesn't realize that Wikibase has nonstandard date handling and
Jarekt added a comment.
I agree that we should have correct translation of phases like "19th century" to English and other languages. On Commons we have dealt with this over a decade ago and you can find translations to various languages at c:Module:I18n/complex_date.TASK
Aklapper added a comment.
The topic of this task is problems in English language due to using full stops in messages. Messages which use the word century was used as one example. The topic of this task is not the use of the word century in messages. Please follow the etiquette to keep discussion
Jc3s5h added a comment.
In T95553#4265262, @kaldari wrote:
@Jc3s5h: I created a new bug for you here: T196674. Now I respectfully ask that you stop spamming this bug with unrelated discussion. Thank you.
No.TASK DETAILhttps://phabricator.wikimedia.org/T95553EMAIL
Jc3s5h added a comment.
I
In T95553#4262897, @kaldari wrote:
@Jc3s5h: This bug has nothing to do with accurately expressing ranges. This bug is about the fact that "5. century" is not valid English and is confusing to English speakers and should be changed to "5th century" (or if that's too
kaldari added a comment.
@Jc3s5h: This bug has nothing to do with accurately expressing ranges. This bug is about the fact that "5. century" is not valid English and is confusing to English speakers and should be changed to "5th century" (or if that's too hard, "5 century"). If the word "century"
Jc3s5h added a comment.
In T95553#4259798, @kaldari wrote:
It looks like y'all are actually discussing T73459, so please feel free to continue there.
I think the solution for both T73459 and this bug would have to involve avoiding the word "century" on both input and output, so the discussion
Jc3s5h added a comment.
In T95553#4259766, @kaldari wrote:
Can y'all please open separate bugs for these other issues and not just dump them all in this bug? Thanks.
A solution must output an _expression_ that will accurately indicate the possible 100 year periods that can be represented in the
kaldari added a comment.
Can y'all please open separate bugs for these other issues and not just dump them all in this bug? Thanks.TASK DETAILhttps://phabricator.wikimedia.org/T95553EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: kaldariCc: Ghouston, Jc3s5h,
Ghouston added a comment.
Yeah, I was wrong about the values getting set to zero, the insignificant digits are retained internally.TASK DETAILhttps://phabricator.wikimedia.org/T95553EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: GhoustonCc: Ghouston, Jc3s5h,
Jc3s5h added a comment.
In T95553#4256969, @Lucas_Werkmeister_WMDE wrote:
The insignificant digits are not always set to zero – you can manually set any date you like and then adjust the precision (example edit). And when you do that, the input shows you how your edit will be interpreted:
Lucas_Werkmeister_WMDE added a comment.
The insignificant digits are not always set to zero – you can manually set any date you like and then adjust the precision (example edit). And when you do that, the input shows you how your edit will be interpreted:
F18803384: Screenshot-2018-6-5 Wikidata
Ghouston added a comment.
I agree with Jc3s5h. Wikidata dates are represented in JSON with ISO 8601 strings with associated precisions, and a "century" precision value looks like:
time: "+2000-00-00T00:00:00Z"
precision: 7
The insignificant digits are always set to zero, apparently, and I'd
Jc3s5h added a comment.
This is being discussed at Help talk:Dates on Wikidata.TASK DETAILhttps://phabricator.wikimedia.org/T95553EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: Jc3s5hCc: Jc3s5h, Larske, VIGNERON, Ayack, matej_suchanek, Hsarrazin,
Jc3s5h added a comment.
I disagree with Lucas_Werkmeister_WMDE. Help:Dates#Precision is correct. It agrees with[[ https://www.mediawiki.org/wiki/Wikibase/Indexing/RDF_Dump_Format | the RDF Dump Format ]] documentation and the the JSON documentation.
As for the idea that "1800s" means the decade
Lucas_Werkmeister_WMDE added a comment.
I think Help:Dates#Precision (permalink) is actually incorrect in this case. There is no year 0 – the first century starts with the year 1 and ends with the year 100, the second century starts with the year 101 and ends with the year 200, and so on.
thiemowmde added a comment.
@Lucas_Werkmeister_WMDE, indeed. My idea is to start simple. Whatever we do, basically everything will be an improvement compared to the current situation. So why not start with the obvious, low-hanging fruit, and take care of the more complicated details later.TASK
matej_suchanek added a comment.
MediaWiki core holds some _javascript_ code for making ordinal numbers in many languages.TASK DETAILhttps://phabricator.wikimedia.org/T95553EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: matej_suchanekCc: matej_suchanek,
Hsarrazin added a comment.
Some contributors in French are very perturbated by this notation, even thinking that the entry (5. siècle} was wrong, and trying to add Q8095 instead...
a solution that would allow to translate the ordinal part of the value would be good.TASK
Lucas_Werkmeister_WMDE added a comment.
To be honest, these examples in the link you posted make me skeptical about the suggested solution… how can we produce some code that produces “whatever is needed”, when there is no such thing as the ordinal form of a number in certain languages, and it can
thiemowmde added a comment.
A very flexible solution that should work with many languages would be to pass an ordinal version of the number as an additional parameter $2 to all messages (no matter if the message needs an ordinal number or not). This way translators are free to use either the
Addshore added a comment.
Would the 'simple' solution here not be to allow the '.' to be a configurable part of the message/ a separate message?
This could be slightly more complex as if we want to have 'st' 'nd' 'rd' and th' for english for example it's not quite as simple as just appending the
PKM added a comment.
I want to say that this bug caused me to refrain from using centuries in this property for years because I was uncertain whether “12. century” really meant 12th century or 1200s ... and I studied German in school, so I am familiar with the German notation. Maybe I’m an edge
thiemowmde added a comment.
Thanks a lot for the kind response. I believe the suggested solution is definitely a way forward: Remove the dot from the message, and use some code that fills the $1 placeholder with "1." or "1st" or whatever is needed. Said code could be NumberFormatter, something
kaldari added a comment.
Anyway, I'm happy to help work on this. I just wanted to see if it's OK to move forward or if it needs more discussion. Didn't mean to start an argument :)TASK DETAILhttps://phabricator.wikimedia.org/T95553EMAIL
kaldari added a comment.
However, I kindly ask you to watch your tone.
Sorry, I legitimately did not intend to express any rudeness. To me, "15. century" is nonsense. I would not guess that it meant "15th century" without context. When I first saw examples of this I thought it was some kind of
thiemowmde added a comment.
Sure, improvements are welcome.
However, I kindly ask you to watch your tone. Neither do we only support 1 language, nor are the values "nonsense". They might be formatted in an awkward, unusual way in many languages. But most readers do have enough imagination to make
kaldari added a comment.
What difference does this make for you, or for anybody else?
The values are nonsense to anyone who doesn't read German.
The concern I do have with utilizing PHPs build-in NumberFormatter (http://php.net/manual/en/class.numberformatter.php) is that it might not be
thiemowmde added a comment.
What difference does this make for you, or for anybody else? If a volunteer wants to start working on this, he should feel free to do so, no matter in which column a ticket is. The #Wikidata board is just a rough overview anyway, and does not really dictate what people
kaldari added a comment.
@thiemowmde: Does this still need further discussion or investigation, or can it be moved to "ready to go" now?TASK DETAILhttps://phabricator.wikimedia.org/T95553EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: kaldariCc:
kaldari added a comment.
So in other words, we should change it to $1 century, and eventually pass $nunberFormatter->format( $number ) as the parameter (instead of just $number).TASK DETAILhttps://phabricator.wikimedia.org/T95553EMAIL
kaldari added a comment.
CLDR has mappings for ordinal numbers in at least 85 languages. I'm pretty sure that's what the PHP intl library is using.TASK DETAILhttps://phabricator.wikimedia.org/T95553EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: kaldariCc:
TheDJ added a comment.
PLURAL simply can not do this
The problem is that this is an ordinal, and we have no tooling for that in our translations. PHP has:
$locale = 'en_US';
$nf = new NumberFormatter($locale, NumberFormatter::ORDINAL);
echo $nf->format($number);
Not sure if there are languages
44 matches
Mail list logo
