npm package discovery and stats viewer.

Discover Tips

  • General search

    [free text search, go nuts!]

  • Package details

    pkg:[package-name]

  • User packages

    @[username]

Sponsor

Optimize Toolset

I’ve always been into building performant and accessible sites, but lately I’ve been taking it extremely seriously. So much so that I’ve been building a tool to help me optimize and monitor the sites that I build to make sure that I’m making an attempt to offer the best experience to those who visit them. If you’re into performant, accessible and SEO friendly sites, you might like it too! You can check it out at Optimize Toolset.

About

Hi, 👋, I’m Ryan Hefner  and I built this site for me, and you! The goal of this site was to provide an easy way for me to check the stats on my npm packages, both for prioritizing issues and updates, and to give me a little kick in the pants to keep up on stuff.

As I was building it, I realized that I was actually using the tool to build the tool, and figured I might as well put this out there and hopefully others will find it to be a fast and useful way to search and browse npm packages as I have.

If you’re interested in other things I’m working on, follow me on Twitter or check out the open source projects I’ve been publishing on GitHub.

I am also working on a Twitter bot for this site to tweet the most popular, newest, random packages from npm. Please follow that account now and it will start sending out packages soon–ish.

Open Software & Tools

This site wouldn’t be possible without the immense generosity and tireless efforts from the people who make contributions to the world and share their work via open source initiatives. Thank you 🙏

© 2026 – Pkg Stats / Ryan Hefner

dictionary-builder

v0.0.8

Published

Install ===

Readme

Install

npm install dictionary-builder

Usage

Building (merging)

i10n/
	messages.js
	main.json // <<-- MAIN DICTIONARY FILE
component/
	places/
		placesPreferences/
			Form.js
			form.l10n.json // <<-- CHAPTER FILE
		interactiveMap/
			Form.js
			description.l10n.json // <<-- CHAPTER FILE
	common/
		Input.js
		index.l10n.json // <<-- CHAPTER FILE

To build main dictionary file from chapters use the next command:

dictionary-builder -i ./test/resources/example/component -o ./test/resources/example/l10n/main.json --chapterFileMask *.l10n.json

Parameters

  • -i REQUIRED. input folder;
  • -o REQUIRED. output file;
  • --chapterFileMask mask of chapter filename. By default used "*.json"
  • --source should be "chapter" for this process direction. Can be left blank

Splitting

The process of distribution of changes in main dictionary file to existing chapters. Main file can be given to manager who will correct the tokens. The main purpose of the tool is to apply changes in main file to files in directories of components.

dictionary-builder -i ./test/resources/example/l10n/expected.json -o ./test/resources/example/splitted --model ./test/resources/example/component --source dictionary --chapterFileMask *.l10n.json

Parameters

  • -i REQUIRED. input file;
  • -o REQUIRED. output folder;
  • --source REQUIRED should be "dictionary" for this process direction
  • --model folder with existing chapters. By default used output folder. Script will use chapters in model directory to recognize where the JSON-brunches should store.
  • --chapterFileMask mask of chapter filename. By default used "*.json"

Notes

If you have existing main dictionary file with all tokens in it then the tool is not fully appropriate for you. The tool uses chapter_first approach. It means that you have to split your main file with directory structure manually. Then the tool can have any price for you. Why?

At first glance I have no ide how to split main file without any model. For example you have:

{
    "en": {
        "toolbar": {
            "user": {
                "session": {
                    "logged_in": "You are logged in as"
                }
            }
        }
    },
... 

What structure of folders do you want at the end?

/l10n
    toolbar/
        user/
            session.l10n.json

with

// l10n/toolbar/user/session.l10n.json
{
    "en": {
        "logged_in": "You are logged in as"
    },
    ...
}

OR

/l10n
    toolbar.l10n.json

with

// l01n/toolbar.l10n.json
{
    "en": {
        "user": {
            "session": {
                "logged_in": "You are logged in as"
            }
        }
    },
    ...
}

Or any other combination?

May be the tool should use some kind on convention to solve the problem, but at the moment it doesn't.

Steps of using:

  1. Create chapters in some folders structure
  2. Run build
  3. Amend main.json
  4. Run split

Мысли по организации файлов локализации нашего проекта с ReactJs

Цель

Словать токенов для нашего веб приложения, который будет использоваться ReactIntl

Пожелания

Для программиста:

  • понятная структура файла локализации. Возможно, привязка к структуре папок компонентов
  • ограниченный размер файла
  • возможность дублирования токенов в разных компонентах
  • хранение файлов локализации под контролем git
  • возможность предоставить словать на редактирование оператору
  • возможность иметь древовидную структуру токенов внутри файла локализации (имеется в виду 2 вида структурирования: по папкам и как родитель/ребёнок внутри json файла)

Для оператора:

  • поиск по тексту токена
  • поиск по структуре приложения

Идеи

Пусть система локализации имеет главы.

Глава - это отдельный json-файлик, который разполагается в директории компонента, который будет его использовать. Тут будут лежать все токены, которые компонент использует.

Нужно создать скрипт, который будет иметь возможность сборки глав в главный файл локализации. Сейчас это /l10n/messages.js

Также нужен скрипт, который сможет выполнять обраное действие. То есть раскидывать изменения в главном файле локализации по файлам, находящимся в директориях компонентов.

Первый способ удобен программисту, так как он имеет маленький файл в директории компонента, имеющий токены относящиеся только к нужному компоненту. И нет необходимости рыться в огромном общем файле для мелких правок.

Второй способ удобен для програмста, когда он дал собранный словарь оператору для изменений. Оператор поправил файл и вернул его программисту. Программист должен:

  • заменить главный файл локализации в проекте
  • при помощиу каких-либо утилит просмотреть правки оператора и удостовериться, что он не сломал структуру JSON файла.
  • запустить скрипт раскидывающий изменения по главам локазизации на уровне компонентов.

Структура компонентов должна при этом быть удобочитаемой. Чтобы оператор при взгляде на интерфейс приложения и JSON файл разобраться в какой ветке находится нужный ему токен. Возможно потребуется следование какой-нибудь конвенции в именовании компонентов.

По большому файлу локализации не проблема найти токен по его тексту.

Идеальный пример

i10n/
	messages.js
	main.json
component/
	places/
		placesPreferences/
			Form.js
			form.l10n.json
		interactiveMap/
			Form.js
			description.l10n.json
	common/
		Input.js
		index.l10n.json
// /component/places/placesPreferences/form.l10n.json
{
	'en-GB': {
		places_range: 'Place range'
	},
	'ru-RU': {
		places_range: 'Диапазон мест'
	}
}
// /component/places/interactiveMap/description.l10n.json
{
	'en-GB': {
		title: 'Service class description'
	},
	'ru-RU': {
		title: 'Описание класса'
	}
}
// /component/common/index.l10n.json
{
	'en-GB': {
		errors: {
			uncaught_exception: 'Uncaught exception. Try to refresh the page'
		}
	},
	'ru-RU': {
		errors: {
			uncaught_exception: 'Неопознаная ошибка, попробуйте перезагрузить страницу'
		}
	}
}
// /l10n/main.l10n.json
{
	'en-GB': {
		places: {
			placesPreferences: {
				form: {
					places_range: "Places range"
				}
			},
			interactiveMap: {
				description: {
					title: 'Service class description'
				}
			}
		},
		common: {
			errors: {
				uncaught_exception: 'Uncaught exception. Try to refresh the page'
			}
		}
	},
	'ru-RU': {
		...
	}
}

Обращение в коде:

this.getIntlMessage('places.places_range.form.places_range');