andreruffert / i18n-literally

🍦 A simple way to introduce internationalization to your JS

i18n-literally

A simple way to introduce internationalization to your JS.

Install

$ npm install i18n-literally

Usage

import i18n from 'i18n-literally';
import db from './i18n.db.json';

// Set the database
i18n.db = db;

// 1. Write in the default language
i18n`Hello ${'World'}!`
// => Hello World!

// 2. Add/update your translations for a language
"$ npx i18n-literally index.js es"

// 3. Get translations based on locale
i18n.locale = 'es';
i18n`Hello ${'World'}!`
// => Hola World!

Write your entire application in the default language, and support multiple versions of the language by simply changing the i18n.locale. To Add/update translations simply run the cli.

API

i18n`template`

Returns a string based on the locale (default "en").

i18n.locale

Type: string Default: en

i18n.db

Type: object Default: {}

CLI

The cli helps you to easily maintain your translations in a simple web app. All translations are stored in a i18n.db.json file.

$ npx i18n-literally --help

  Usage:
    $ literally <cmd> <entry> <locale> [db]

  Arguments:
    <cmd>       Command defaults to "edit" (edit, check-missing-translations)
    <entry>     The entry file of your app
    <locale>    Locale to add/update translations for
    [db]        Database file defaults to "./i18n.db.json"

  Options:
    --root      Project's root directory (default: $PWD)
    --rootAlias Alias used by imports for project's root
    --help      Show information
    --version   Show current version

  Examples:
    $ literally edit ./index.js es
    $ literally edit ./src/index.js en --root=src --rootAlias=~

The cli web app to add/update translations.

Related

Inspired by this post from Andrea Giammarchi.

License

MIT © André Ruffert

i18n-literally's Issues

CLI cmd to test for missing translations

The goal of this feature is to be able to run a script on e.g. a CI to prevent deployments of missing translations.

$ literally has-missing-translations
// => 0 || 1

Project root alias

Hello Andre!

First of all, thank you for making this tool. I have been planning to follow this style of i18n implementation since reading the original article by @WebReflection.

In my current project, we are using babel-plugin-module-resolver with an alias to the project root (~).

This presents a problem because many imports in the project do not look like a relative import since they do not start with a dot.

Are you open to a merge request that adds the ability to pass --root and --rootAlias arguments so that aliased imports will resolve properly?