Skiver

An easy to-deploy, single binary management for translations. Focuses on tight integrations.

CLI

If you are looking for the accompanying CLI, it has been moved to its own repository.

Current feature-set

Exports

You own your data. At any time, you can export all information recorded, and convert it to any supported format.

Extended typescript-support

The types generated for use in typescript-projects gives a better insight for developers as to what each key in the translation means.

Depending on the tooling used, developers could only see the key for the translation, with very limited information about the meaning of the key without consulting a different system.

With these types generated, the developer can see examples of the real translation directly in their editor, along with any parameters used.

Hover-information in Visual Studio Code

Tooltip in VIM

• Multi-locale support

• Multi-project support

• i18n-compliant export

• Auto-translate via external translation-service (Bing Translate, Libre Translate)

• Report missing translation

  • Missing translations can easily be viewed and created from the UI.

• Typescript-type-generation with rich comments

• Import translations

  • General AST
  • Dry run, with preview of updates and creations
  • i18next-format
    • multiple-language
    • context-support
    • inferring of variables and nested keys.

• Multi-organization support

Planned feature-set

• Server-side interpolation via API

• Client-side live interpolation via library

  • Support for multiple libraries, including different versions.
  • Optionally bring your own library, per project. Upload any WebAssembly with the library included, and it will be used on all translations.

• Source-code integration with project, to show usage of translation.

  E.g.

  This translation is used in SuperComponent.svelte:74: jsx 73: <div> 74: <p>{t("feature.awesome", {count: 6})} 75: </div>

• Upload of images to show usage of translation.

• Sharing of translations between projects.

Contributing / notes about the project

We welcome and encourage contributions. If you have a feature that you wish to incorporate, please add an issue first to discuss it.

Swagger and code-generation

We use swagger, with go-swagger for both generating parts of the Swagger 2.0-document, and for providing Go-Models for server-use as well as typescript-models for frontend.

The base-swagger is extended with code-generation, and can be used to manually define parts of the swagger-file.

This information includes base-information like application description, versioning etc, routing and user-input (parameters).

The generated user-input-models are output into ./models.

Extra types are generated from the go-structs itself, and lives in the ./types-package.

Committing generated files

Although some people prefer not to commit generated files, the generated swagger files with models etc. should in this project be committed like any other file.

This makes it a lot easier to reason about changes, and we are then not at the mercy of code-generation. We still can at any point drop out of using code-generation for parts of, or the whole schema.

Tools used

There is a makefile available which makes it a bit easier to do development.

Simply running make without arguments should start the development server in watch-mode, and reload as needed.

It has a few general require utilites:

• ripgrep Fast searching through files
• fd Fast finding of files with gitignore-support, among other nice things.
• entr Simple file-watcher

These are general tools that I highly recommend as part of a development-environment, not just for running this project.