Gathering detailed insights and metrics for gettext-utils
Gathering detailed insights and metrics for gettext-utils
Gathering detailed insights and metrics for gettext-utils
Gathering detailed insights and metrics for gettext-utils
node-gettext
A JavaScript implementation of gettext, a localization framework
gettext-parser
Parse and compile gettext po and mo files to/from json, nothing more, nothing less
gettext-extractor
Gettext extractor for JavaScript, TypeScript, JSX and HTML
jed
Gettext Style i18n for Modern JavaScript Apps
npm install gettext-utils
Module System
Min. Node Version
Typescript Support
Node Version
NPM Version
3 Stars
100 Commits
1 Forks
3 Watching
12 Branches
2 Contributors
Updated on 10 Jun 2022
TypeScript (80.32%)
JavaScript (16.84%)
Shell (2.83%)
Cumulative downloads
Total Downloads
Last day
67.9%
47
Compared to previous day
Last week
14.1%
146
Compared to previous week
Last month
-0.4%
505
Compared to previous month
Last year
45.9%
8,388
Compared to previous year
9
A set of utils to extract strings from JS application to .pot file, merge it with existing .po files and / import these strings back to a react-targem or lioness compatible .json file / validate that all the strings are translated before release
npm i --save-dev gettext-utils
export-strings [input-files-glob] [output] [--default-locale=locale] [--po-files-path]
parse through all the files provided in input-files-glob
(src/**/{*.js,*.jsx,*.ts,*.tsx}
by default) (uses glob) and generate .pot file in the output path (./src/i18n/template.pot
by default). Then searches for all the .po
files in the same directory and updates them with new strings to translate. If default-locale
is provided (e.g. en
) and this locale's .po
file exists in the same folder (e.g. en.po
), this file will be populated with the translations automatically. You can specify additional path(s) to update .po
files by using --po-files-path your/custom/folder your/other/directory
.import-strings [po-files-path] [output] [--optimize=true] [--split-by-locale=false]
parse all the .po
files inside the directory provided as po-files-path
(./src/i18n/
by default) and generate react-targem or lioness compatible .json
file in the output path (./src/i18n/translations.json
), which is an object with each locale as a key and gettext-parser object for this locale as a value. By default all translations.json
are optimized, e.g. all unnecessary fields are removed. Pass --no-optimize
or --optimize=false
to disabled optimizations. You can also pass --split-by-locale
option to write translations for different locales into separate files.merge-translations [po-files-dir-path] [template-path]
merge updated .pot file with .po. Done automatically by export-strings
command. If default-locale
is provided (e.g. en
) and this locale's .po
file exists in the same folder (e.g. en.po
), this file will be populated with the translations automatically.validate-strings [po-files-dir-path] [template-path]
validate all .po
files inside po-files-dir-path
(./src/i18n/
by default) to have all the translations in the .pot
file provided in template-path
(./src/i18n/template.pot
by default).For example, you have a react project in src
folder and you want to use react-targem or lioness to translate your application.
npm i --save react-targem
or npm i --save lioness
npm i --save-dev gettext-utils
<T>
component or withTranslations
HOC.npx gettext-utils export-strings
to create a src/i18n/template.pot
file.prestart
and prebuild
scripts inside scripts
section of your package.json
: "prestart": "gettext-utils import-strings"
to generate translations.json
file automatically./src/i18n/translations.json
file inside your .gitignore
(this file is generated automatically).gettext-utils export-strings --default-locale=en && git add src/i18n/*
in any precommit hook you are using, so the translations will be exported automatically (husky).develop
branch before relase.npx gettext-utils validate-strings
to make sure that everything is translated before each release.No vulnerabilities found.
Reason
no binaries found in the repo
Reason
Found 4/22 approved changesets -- score normalized to 1
Reason
0 commit(s) and 0 issue activity found in the last 90 days -- score normalized to 0
Reason
no effort to earn an OpenSSF best practices badge detected
Reason
security policy file not detected
Details
Reason
license file not detected
Details
Reason
project is not fuzzed
Details
Reason
branch protection not enabled on development/release branches
Details
Reason
SAST tool is not run on all commits -- score normalized to 0
Details
Reason
22 existing vulnerabilities detected
Details
Score
Last Scanned on 2024-11-18
The Open Source Security Foundation is a cross-industry collaboration to improve the security of open source software (OSS). The Scorecard provides security health metrics for open source projects.
Learn More