cospired / i18n-iso-languages Goto Github PK

Hey everyone,

I have a project, where the npm install or npm ci fails on Jenkins because this package has its .git folder packed.

npm ERR! path /srv/jenkins/workspace/someProject/node_modules/@cospired/i18n-iso-languages
npm ERR! code EISGIT
npm ERR! git /srv/jenkins/workspace/someProject/node_modules/@cospired/i18n-iso-languages: Appears to be a git repo or submodule.
npm ERR! git     /srv/jenkins/workspace/someProject/node_modules/@cospired/i18n-iso-languages
npm ERR! git Refusing to remove it. Update manually,
npm ERR! git or move it out of the way first.

I can reproduce that the .git folder gets installed via npm i https://github.com/cospired/i18n-iso-languages.git (npm 6.4.1, node v10.15.3, macOS 10.14.6).

When I wanted to open a PR I can not reproduce the error with npm pack locally. Maybe you built it with another npm version?

Usually a .npmignore file with a .git entry should prevent it from being packed.

Please let me know if you can reproduce it.

I would be happy to help!

Cheers,
Jonah

Hello language lovers,
(Language here refers to whether(or both) programming languages or natural languages. 🚀)

First of all, thanks for creating and maintaining this great repo. My colleagues and I love it!

I'm wondering if it's possible for me to contribute a new language which its code is 'zh-TW'(Traditional Chinese).

I know that zh-TW doesn't exist on the list of ISO 639-1, but that's the official language of Republic of China(Taiwan) which means that it's used by more than 24,000,000 people.

People might wonder what's the difference between zh and zh-TW, is it really necessary to add zh-TW.
Well, the two languages are very different from each other, for example

1. The characters are different:

2. The translations of languages between zh and zh-TW may be different, when it comes to:

• Azerbaijani: we say "亞塞拜然語" instead of "阿塞拜疆语".
• Lao: we say "高棉語" instead of "老挝语".
• Kinyarwanda: we say "盧安達語" instead of "卢旺达语".
• Venda: we say "溫達語" instead of "文达语".
  ... etc

I'm ready to contribute but instead of pulling a request, I think it's better to have a conversation to discuss about this beforehand. Since it's an open source repo 🙂.

Thanks for reading!

Shouldn't the entry for "Bihari languages" just be "Bihari" in langs/en.json (i.e. singular instead of plural, like it is for the other langs/*.json files)?

Frysian is.

The list of German language names (langs/de.json) contains a number of inaccuracies:

In addition, there are some entries that are technically correct, but do not represent the most common German name:

aka BCP47/RFC5646

Expand databases to add tranlations of 639-2 languages, that's it, the ones with three-letter codes without an equivalent two-letter code. The list of 639-2 languages codes is available at https://en.wikipedia.org/wiki/List_of_ISO_639-2_codes.

Here is a quick test case:

mkdir testcase
cd testcase

git init
npm init --y

npm i --save-prod @cospired/i18n-iso-languages
npm i -g typescript

mkdir src
cd src

Create the file testcase.tswith following content:

import { isValid as isValidLanguageCode } from "@cospired/i18n-iso-languages"

console.log(`isValidLanguageCode: ${isValidLanguageCode("en")}`);

Compile and execute it:

tsc testcase.ts

node testcase.js

D:\Projects\private\testcase\node_modules\@cospired\i18n-iso-languages\index.js:265
  return this.toAlpha3T(code) !== undefined;
              ^

TypeError: Cannot read property 'toAlpha3T' of undefined
    at exports.isValid (D:\Projects\private\testcase\node_modules\@cospired\i18n-iso-languages\index.js:265:15)
    at Object.<anonymous> (D:\Projects\private\testcase\src\testcase.js:4:72)
    at Module._compile (internal/modules/cjs/loader.js:1063:30)
    at Object.Module._extensions..js (internal/modules/cjs/loader.js:1092:10)
    at Module.load (internal/modules/cjs/loader.js:928:32)
    at Function.Module._load (internal/modules/cjs/loader.js:769:14)
    at Function.executeUserEntryPoint [as runMain] (internal/modules/run_main.js:72:12)
    at internal/main/run_main_module.js:17:47

If I remove the this. above, it will work.

According to index.d.ts, the function getAlpha2Code always returns a string. According to the unit tests, it returns a string on success, undefined otherwise.

The type definition should be changed to read

export function getAlpha2Code(name: string, lang: string): string | undefined;

I suspect that the same is true for most of the functions.

the current build started to fail for node 4.
we might just drop node 4 support by now anyways

this needs an additional list of all the languages in its own language

source Wikipedia and other sources