Closed jacargentina closed 6 years ago
Great! So we should have a disclaimer on the README page that the library is locale/language dependent.
I think that in this case this is more of an enhancement than a bug, given that the library wasn't built with i18n in mind, and that we can't cover all languages programmatically.
We can manually extend the i18n coverage with something like the following:
new RegExp(...)
with the keys dynamically fetched from the i18n dictionaryLet me know what you think,
Have a wonderful day ✨
@philippefutureboy I was thinking of another easier solution: we can force the environment for the child_process to have the LANG we need, ie LANG=en_US.utf8
... using options.env, right?
I wasn't aware of this. If this is possible, it's marvelous :O
Is this possible across all computers or the user needs to have the English language pack installed?
Yeah, corelibs from linux distros are english by default; think macOS the same. No "language packs" needed.
I 've found on my work linux box that it fails to parse correctly; added my linux command output in a new file for testing static output; refactored the parsing to be stronger; now it works
Wonderful! Let me know how it goes for the MacOS side of things
I'm now trying to make parsing even better; if the user has no enough permissions, fdisk show errors, and then parsing is affected with strange errors like calling slice
on an empty matches array.
Fix/4 is now included here.
I've found that parsing currently depends on specific english strings; i'm from Argentina (spanish).
For example,
npm run test
withLANG=es_AR.utf8
makes test fail like this:null
is a failingmatch
for the string/Disk\s(.*):\s.*,\s(\d+)\sbytes,\s(\d+) sectors/
on src/linux/linux.js:116On spanish Disk is Disco