[02:30:48] I got it on a language too : https://tools-static.wmflabs.org/bridgebot/a6c920f0/file_68848.jpg [03:14:09] I suggest we use the following functions as a reader and display function for the Byte Type: [03:14:10] read Gregorian Year (https://www.wikifunctions.org/view/en/Z22910) (https://www.wikifunctions.org/view/en/Z22910)(Z22910) (https://www.wikifunctions.org/view/en/Z22910) [03:14:11] display Gregorian Year (https://www.wikifunctions.org/view/en/Z22925) (https://www.wikifunctions.org/view/en/Z22925)(Z22925) (https://www.wikifunctions.org/view/en/Z22925) [03:14:13] Feel free to add a localised function for your language to the configuration if you would like to replace the default display function which uses ISO 8601 integer strings. Adopting the English AD/BC is not the best default here. (re @vrandecic: Newsletter #191 [03:14:14] * From things to words [03:14:16] * Volunteers’ Corner on March 3 [03:14:17] * Recent Changes in the software [03:14:19] * Function of the Week: ...) [03:17:55] The reader also currently relies on Z20198, which is English-centric, and can't deal for example with Spanish "753 a. de C. (https://www.wikifunctions.org/view/en/Z22917)" so it would also be nice to see a set of localised string readers for configuration. (re @u99of9: I suggest we use the following functions as a reader and display function for the Gregorian Year [03:17:55] Type: [03:17:56] read Gregorian Year (Z22...) [03:31:15] Would anyone favour a traditional English config with "AD 2025" instead of "2025 AD"? If so, to which English variants should it apply? [04:12:32] One issue I just picked up that we should sort out. These are inconsistent: Z22932 and Z20205. I think we should go with ISO 8601, but it's a tough call, because people will often type "-512" to mean 512 BC. (re @u99of9: I suggest we use the following functions as a reader and display function for the Gregorian Year Type: [04:12:32] read Gregorian Year (Z22...) [04:53:04] In 'Murica I've only seen it as 2025 AD (though I've heard AD 2025), so my vote is to keep 2025 AD (re @u99of9: Would anyone favour a traditional English config with "AD 2025" instead of "2025 AD"? If so, to which English variants should it...) [05:05:50] I think the best principle would be to always go with whatever the plurality of English speakers use, but that makes us biased towards Indian English (which is especially difficult considering we have very few contributing Indian English speakers) [05:06:15] And secondarily biased towards American and Nigerian English [06:00:54] Here is a Day of Roman Year display function Z22941. Every language other than English gets a rubbish format (a superseded ISO format) until they write their own localisation! IMO it's actually worse for those languages than the Wikifunctions default un-rendered output. So I think we should consider *not* adding this display function until either localisations are [06:00:54] written, or we [06:00:55] can make a generic that looks up month names in many languages from Wikidata. (re @vrandecic: Newsletter #191 [06:00:56] * From things to words [06:00:58] * Volunteers’ Corner on March 3 [06:00:59] * Recent Changes in the software [06:01:01] * Function of the Week: ...) [06:09:17] I've just discovered that we don't have an object for Indian English. This means we currently *can't* configure natural numbers better for that variant. (re @Feeglgeef: I think the best principle would be to always go with whatever the plurality of English speakers use, but that makes us biased t...) [06:09:50] Yikes (re @u99of9: I've just discovered that we don't have an object for Indian English. This means we currently *can't* configure natural number d...) [06:10:00] Probably should be created [06:10:29] And they do it differently (re @u99of9: I've just discovered that we don't have an object for Indian English. This means we currently *can't* configure natural number d...) [06:10:35] That really sucks [06:20:12] T387546