[Feature request] Configurable [locale] code

[seppviljar]

Hey, this is completely convenience feature ask but it might be useful for many.

In some cases locale code in target files do not match with lingo.dev official [locale], a la we use short versions wherever possible( nb.strings, zh.strings, pt.strings for pt-BR). This seems to require constant back and forth renaming step.

Would be nice, if configuration supported "<lingo.dev locale>: " mapping possibility. Ideally on bucket level (below) but having it on global level would be already a win if you don't have more than one file format.

{
  "version": 1.2,
  "locale": {
    "source": "en",
    "targets": [
      "ar-EG",
      "bg",
      "nb-NO",
      "sr-Latn-RS",
      "zh-Hant",
      "zh-Hans"
    ]
  },
  "buckets": {
    "xcode-strings": {
      "include": [
        {
        "path": "[locale].strings",
        "delimiter": "_"
        "locale": {
          "source": "en",
          "targets": {
            "ar-EG": "ar",
            "bg",
            "nb-NO": "nb",
            "pt-BR": "pt"
            "sr-Latn-RS": "sr-Latn",
            "zh-Hant",
            "zh-Hans": "zh"
          }
        }
      ]
    }
  },
  "$schema": "https://lingo.dev/schema/i18n.json"
}

So the conf like this would read files with local file patterns and give me back:

• ar.strings
• bg.strings
• nb.strings
• pt.strings
• sr_Latn.strings
• zh_Hant.strings
• zh.strings

PS. Whether to require "delimiter" or allow this be set also here, no opinion...

[maxprilutskiy]

Great idea @seppviljar mind sharing more details why would you like to re-map the locale codes?

I'd like to understand the idea behind the idea, to make sure it will make sense for the rest of the users too, when we add this.

What's the use case?

[seppviljar]

Thanks @maxprilutskiy

It’s more about mapping Lingo.dev’s locale codes to our (custom) file names — so I can use my current files without having to rename them first to Lingo.dev’s expected locale format and then back again. Mapping support in Lingo.dev would let me avoid those two extra, inconvenient steps.

It also makes it a bit more predictable. For example, mapping "pt-BR": "pt" ensures that my existing file is both directly modifiable and also clearly tied to the Brazilian version — not Portuguese (Portugal), which might be the default for a two-letter locale code.

[maxprilutskiy]

awesome idea @seppviljar, let's do that!

[partik03]

@maxprilutskiy I want to take up this one

[maxprilutskiy]

go ahead @partik03 !

hmu on discord when you have questions, let's align on how the final design should look like here

[maxprilutskiy]

unassigning from @partik03 as there's been no pr

[maxprilutskiy]

up for grabs!

[namanguptagit]

Hi everyone 👋

I’d like to take up this issue and implement the locale code remapping feature as discussed. The idea is to let users define a mapping between their own locale codes (like pt or nb) and the standard locale codes used internally by Lingo.dev (like pt-BR or nb-NO).

Proposed Approach

1. Add a new config property (e.g., locale_map) inside lingo.config.json or .lingorc:

{
  "locale_map": {
    "pt": "pt-BR",
    "nb": "nb-NO"
  }
}

2 . Update locale resolution logic — likely in a file such as src/utils/locale.js — to check for remapped codes before validation or loading:

function resolveLocale(code, config = {}) {
  if (config.locale_map && config.locale_map[code]) {
    return config.locale_map[code];
  }
  return code;
}

module.exports = { resolveLocale };

3 . Integrate this helper wherever locale codes are being checked or normalized — for example, in the CLI sync or project load commands:

const { resolveLocale } = require('./utils/locale');

const locale = resolveLocale(userLocale, config);
// Continue with the remapped locale...

4 . Add unit tests to verify remapping and fallback behavior:

const assert = require('assert');
const { resolveLocale } = require('../src/utils/locale');

const config = { locale_map: { pt: 'pt-BR' } };

assert.strictEqual(resolveLocale('pt', config), 'pt-BR');
assert.strictEqual(resolveLocale('en', config), 'en');
console.log('✅ Locale remapping tests passed');

5 . Documentation: Add a note to the CLI config docs about locale_map usage and behavior when not specified.

If this approach aligns with your expectations, I’ll go ahead and open a PR implementing it. Happy to adjust the config key name or scope (e.g., per-bucket) if needed before starting.

Thanks! Naman Gupta