Add Latin locale #961
Comments
We use ISO 639-2 country code. |
Arabic numerals = 1, 2, 3, … Roman numerals = I, II, III, IV, … Date example: XX Iunii MMXX = 20 June 2020 Time format would 24h in Arabic numerals, e.g. 13:24. Now, my question is about the conversion from Arabic numerals to Roman numerals: is there a builtin converter or should I create a function within the locale? If I need to create a function and I create it in the main,
|
|
2 the best way might just be simple copy-paste. Yes, you have to create a function to make the conversion in locale file. |
|
I have created the Anyway, as there is no I wanted to test the locale locally, but with my limited knowledge I could not make it work. This is what I have done:
const dayjs = require('./dayjs.min.js');
dayjs.locale('la')
var l = dayjs.locale()
console.log(l)
Now, I have read the docs, but adding $ node testLa.js
internal/modules/cjs/loader.js:960
throw err;
^
Error: Cannot find module 'dayjs/locale/la'
Require stack:
- /home/ts/git/c10n/dayjs/testLa.js
at Function.Module._resolveFilename (internal/modules/cjs/loader.js:957:15)
at Function.Module._load (internal/modules/cjs/loader.js:840:27)
at Module.require (internal/modules/cjs/loader.js:1019:19)
at require (internal/modules/cjs/helpers.js:77:18)
at Object.<anonymous> (/home/ts/git/c10n/dayjs/testLa.js:2:1)
at Module._compile (internal/modules/cjs/loader.js:1133:30)
at Object.Module._extensions..js (internal/modules/cjs/loader.js:1153:10)
at Module.load (internal/modules/cjs/loader.js:977:32)
at Function.Module._load (internal/modules/cjs/loader.js:877:14)
at Function.executeUserEntryPoint [as runMain] (internal/modules/run_main.js:74:12) {
code: 'MODULE_NOT_FOUND',
requireStack: [ '/home/ts/git/c10n/dayjs/testLa.js' ]
}I understand that the module was not found, but even if I change the path to Anyway, I’ve just create a PR, but it definately needs to be reviewed. |
|
Sorry, I was busy lately. Could you help me with running |
|
I would manually change 'dayjs/locale/la' to '../src/locale/la' 😢 |
Where would you do that? |
to replace this |
|
I have tried out your suggestion, but it still does not work, see below. All my scripts are located in the repo root.
|
|
please use |
|
Indeed, you’re right, there are failing tests, but I did not change anything in those files. Failing testsSummary of all failing tests
FAIL test/parse.test.js
● Parse › moment-js like formatted dates
expect(received).toBe(expected) // Object.is equality
Expected value to be:
"2018-01-01T00:00:00+01:00"
Received:
"2018-01-01T01:00:00+01:00"
37 | expect(dayjs(d).valueOf()).toBe(moment(d).valueOf()) // not recommend
38 | d = '2018'
> 39 | expect(dayjs(d).format()).toBe(moment(d).format()) // not recommend
40 | d = '2018-05-02T11:12:13Z' // should go direct to new Date() rather our regex
41 | expect(dayjs(d).format()).toBe(moment(d).format()) // not recommend
42 | })
at Object.<anonymous> (test/parse.test.js:39:31)
FAIL test/plugin/utc-utcOffset.test.js
● change hours when changing the utc offset in UTC mode
expect(received).toBe(expected) // Object.is equality
Expected value to be:
5
Received:
4
70 | expect(d.hour()).toBe(6)
71 | expect(d.utcOffset(0).hour()).toBe(6)
> 72 | expect(d.utcOffset(-60).hour()).toBe(5)
73 | expect(d.utcOffset(60).hour()).toBe(7)
74 | expect(d.utcOffset(-30).format('HH:mm')).toBe('06:01')
75 | expect(d.utcOffset(30).format('HH:mm')).toBe('07:01')
at Object.<anonymous> (test/plugin/utc-utcOffset.test.js:72:35)
● keep hours when adding month in offset mode
expect(received).toBe(expected) // Object.is equality
Expected value to be:
6
Received:
5
94 | const dm8 = dayjs('2000-01-30T06:31:00-08:00').utcOffset(-8)
95 |
> 96 | expect(d10.add(1, 'month').hour()).toBe(6)
97 | expect(dm8.add(1, 'month').hour()).toBe(6)
98 |
99 | expect(d10.add(-2, 'month').hour()).toBe(6)
at Object.<anonymous> (test/plugin/utc-utcOffset.test.js:96:38)
FAIL test/plugin/calendar.test.js
● No argument && null && undefined
TypeError: Cannot convert undefined or null to object
at hasOwnProperty (<anonymous>)
17 | it('No argument && null && undefined', () => {
18 | expect(dayjs().calendar()).toEqual(moment().calendar())
> 19 | expect(dayjs().calendar(null)).toEqual(moment().calendar(null))
20 | expect(dayjs().calendar(undefined)).toEqual(moment().calendar(undefined))
21 | })
22 |
at hasOwnProp (node_modules/moment/moment.js:42:48)
at isMomentInputObject (node_modules/moment/moment.js:3669:44)
at isMomentInput (node_modules/moment/moment.js:3629:13)
at Moment.calendar (node_modules/moment/moment.js:3729:17)
at Object.<anonymous> (test/plugin/calendar.test.js:19:51)
Test Suites: 3 failed, 52 passed, 55 total
Tests: 4 failed, 505 passed, 509 total
Snapshots: 0 total
Time: 27.64s
Ran all test suites.
npm ERR! Test failed. See above for more details. |
|
All of our tests should be passed. You can submit a pull request with any change and test with our CI to see if there is an environmental issue. |
|
I’ve no idea how to fix those errors, but somehow it uses GMT+1 timezone instead of UTC. Note that I use CET (winter timezone; GMT+1) and CEST (summer timezone; GMT+2) locally; although it should not be connected, it might be. |
|
I'll try CET to see if I can reproduce this later. |
|
@iamkun, I have just cloned your repo (
|
|
Oh, I see. Because of DST, some of the tests failed because of a fixed datetime string |
|
Hi, @tukusejssirs I have made a pr #1053 to fix this issue. Can you please help me test it to see if it works? |
|
@iamkun, I still have no idea why all the above-mentioned test scripts of mine fail to use I have run Also if I import or require I am fairly sure that this are a newbie mistake, but it seams I can’t find it. AFAIK, Thanks for your help. |
|
you can check this as a reference test/locale/cs.test.js and create a test file to test Latin locale |
|
I cannot do it the way it is in I need to do it the way it is in Still, I’d like to have test script before I push it to the repo, therefore I wish I could run a script using the Note that I could not make
Anyway, I don’t care how this would be solved, as long as I can use |
|
What I mean is that you could create a test file named Then just run |
|
Can you tell me why And Update: I needed to add import localizedFormat from '../../src/plugin/localizedFormat'
dayjs.extend(localizedFormat)But now I receive // la.js
LL: ['D ', getMonthInGenitive('MMMM'), ' ', romanise('YYYY')].join(''),
// la.test.js
console.log('testLL : ', dayjs('2020-01-01').locale('la').format('LL'))
// output in `npm test`
testLL : 1 NamN
// expected output in `npm test`
testLL : 1 ianuarii MMUpdate 2: One of the problems lays in the argument of |
I understand what you mean, but I still want to be able to run a script using |
|
It will be better if you could test it your self, cause I don't know much about the |
Okay, I see I can’t make you help me with this subissue. 😃 I’ll run
Well, actually I have tested it, but within a separate script (i.e. without using That function is quite simple: it accepts one argument (a month name in Latin in nominative) and returns the genitive form of that month. The whole problem is that I don’t know how to send it the name of the month in PS—I don’t even understand, how the |
|
If I understand you correctly, https://day.js.org/docs/en/customization/relative-time#additional-token-processing is what you are looking for about |
That might work, however, does it work with |
|
No at this moment.
|
|
Then my functions in Unless you know of another way. Here is what I need to do with
PS:
|
|
Something you can do is that month name also accepts a function with days instance and format passed in https://day.js.org/docs/en/customization/month-names#additional-token-processing |
You mean I can replace months: function (dayjsInstance, format) {
if (/^MMMM/.test(format)) {
return 'ianuarius_februarius_martius_aprilis_maius_iunius_iulius_augustus_september_october_november_december'.split('_');
} else {
return 'ianuarii_februarii_martii_aprilis_maii_iunii_iulii_augusti_septembris_octobris_novembris_decembris'.split('_');
}
},Update: No, it does not. It returns all months in genitive (comman-separated), therefore it is a good step forward, but we ain’t there yet. 😃 Update 2: I think I need to know what are the Update 3: Nevermind, I’ve fixed it using the code from |
|
Last thing to fix is the conversion of the year from Arabic numerals to Roman numerals. I have a function ( IMHO, it might a better idea to implement it into For example:
Update: Here’s link to Update 2: I tried the following code (based on const romaniseYear = (dayjsInstance, format) => {
return romanise(dayjsInstance.year())
} |
|
I'd prefer it as a separate plugin. |
|
Is that something you could create and place under |
|
Oh, sorry I just misundertand what you mean. IMO, just leave this romanise() function in the locale file. That would be enough right now. |
I’ve no problem with that, however, how can I add the year (as an int) as argument to the function? Update: Just a reminder: I need to romanise the year in |
|
As far as I can tell, seems there is no way to convert year to anything other than the year number. You may still have to consider making a plugin like |
Okay, I’ll do my best.
|
|
@iamkun, in case I cannot replace the year in
If you disagree with these, let me know. Anyway, I tried to modify the code in The thing is, it does not work for some reason. As you can see, I left there
|
|
@tukusejssirs Is there something we can check as a reference of the format token? like JAVA or something. And actually, this plugin is becoming much more complex than we expected earlier, and we may release it in a separate repo like https://github.com/alibaba-aero/jalaliday so that you can get better control of the code logic, cause it's difficult for us to maintain these logic. |
No reference, because I couldn’t find any programming language with Roman numerals for year/dom/month implemented. Those date format (
If you can guide me … Because I am not an experienced programmer (am I a programmer at all?). All I need is Latin locale for romcal, which use
May I know what is the difficult part of this logic? 😃 |
|
Day.js accepts all PRs related to adding locale. However, as for official plugins, we'd like to keep it in a fixed amount,maybe, just enough to add APIs the same as moment.js. That's why I advice you to to manage this plugin by your own. |
Okay, I got it. Just a quick question: therefore there is no way (or intention) to add a plugin for romanisation of the year to the list of the official plugins? |
|
I don't think we have the ability right now. |
|
@iamkun, how can I test ordinal numbers? Does it only work with |
|
Yes, ordinal only works for As far as I can see, it's better to make a plugin yourself for the romanization ordinal to get the best result that you expected. Cause it has too much different than other locales that we supported. |
Thanks for clarification. 😃
Well, indeed you don’t support romanisation at all, but that does not mean that it is not used by real humans. For example, in Hungarian, one can use I don’t say that you are required to implement it, but please do consider implementing a flag for this within |
|
@tukusejssirs Of course I know it's an important language. However, bundle extra logic to the main pack will significantly increase the bundle size, while the use is limited. In this case like many others, we recommend implementing it as a separate self-maintained plugin to make it fully supported. |
It's not true that the Hungarians writing months like XII. We can and allowed but never used. We use number: 1,2,3...12 |
For romcal, I need to add Latin locale to
dayjs. Therefore I have some questions regarding this.feria secundafor Monday), should I use a command as follows?A. using
dies(used in the Ancient Rome):dies Solis;dies Lunae;dies Martis;dies Mercurii;dies Iovis;dies Veneris;dies Saturni;B. using
ferias(numbering days, starting with 1 for Sunday):feria prima;feria secunda;feria tertia;feria quarta;feria quinta;feria sexta;feria septima;C. variation of the
ferianames, used in the RC Church (usesDominicafor Sunday andSabbatofor Saturday):Dominica;feria secunda;feria tertia;feria quarta;feria quinta;feria sexta;Sabbato.Now, I need the C one only, but some other people might like some other names. If I implement this, I’d like to be as thorough as possible, so my question is: should I create three separate regions (like
la-vafor Vatican, i.e. the 3rd type of weekday names)? Or how else should I fix this?ferianames are used, one may shorten it by using Roman numerals (e.g.feria sexta→fera VI). I presume I should use these inweekdaysShort, but I need a confirmation. Seldom, simply the Roman numerals are used (likeIV), for which I could useweekdaysMin.dayjsinclude such a converter? Should I create a custom function withinla.js?dayjswith the output of Moment indayjstests, is it required to createla.jslocale in Moment first?The text was updated successfully, but these errors were encountered: