Message extraction feedback

[amannn]

Please use this thread to share feedback related to useExtracted.

This is my public TODO list for the feature: #2087 (but please keep the feedback here)

[amannn]

Question from @jurerotar:

A question I have is whether namespacing of messages will also be supported? I realize this is more of a SPA-related issue, but perhaps there are some use cases in Next.js apps where a developer is loading the localizations to the client and may want to split them up.

Answer:

Yep, namespaces are being considered, they are currently only briefly mentioned in regard to monorepos in the catalog generation section.

E.g.:

const t = useExtracted('namespace');
t('Hey there!');

… would generate e.g.:

{
  "namespace": {
    "5VpL9Z": "Hey there"
  }
}

I think the point is valid and this should be clarified more visibly (and perhaps not just be a "future exploration").

The ultimate goal for next-intl regarding splitting of messages for performance is #1, but as a stopgap solution some developers might find value in using some namespaces for this.

Does that answer the question?

[jurerotar]

Awesome, this looks really great!
Thank you very much for taking the time and clarifying this for me!

[amannn]

Quick poll: After reading the section on File formats & AI translation, which file format would you prefer as a default?

• 🚀 Portable object (.po)
• 🎉 Simple JSON (no contextual descriptions)
• 👀 Structured JSON (with vendor-specific format)

[niieani]

btw. why no YAML option? (that's what we use)

[amannn]

Can you share an example snippet how this looks in detail? And is it based on a standard, or something you've defined for yourself?

[niieani]

Similar to your Structured JSON option, just in YAML. JSON has the issue of merge conflicts due to commas.
The output YAML is just a long array of strings, each defining the id, message and other options like the ones you would add in structured JSON. This is only to store the extracted strings. The consumable format that's downloaded by the app is either JSON files or JSON in JS files (extra trick for perf) + the default/fallback language embedded by the transpiler in the t() calls.

[amannn]

I see, got it! Yeah I think custom formatters will likely be necessary, just because people have different preferences here. Maybe support for some popular ones OOTB would be good though.

extra trick for perf

Super interesting, thanks for sharing!

[Carlwirkus]

The default not being JSON or structured JSON feels like a mistake. I'd be optimising for familiarity rather than efficiency. Provide an option for custom outputs if it's really that much better.

Cool idea though! keen to give it a go.

[amannn]

Another poll: Do you prefer useExtracted or useInlined as the hook name?

import {useExtracted} from 'next-intl';

function InlineMessages() {
  const t = useExtracted();
  return <h1>{t('Look ma, no keys!')}</h1>;
}

import {useInlined} from 'next-intl';

function InlineMessages() {
  const t = useInlined();
  return <h1>{t('Look ma, no keys!')}</h1>;
}

Please vote with your preference:

• 🚀 useExtracted
• 🎉 useInlined

I'd also appreciate if you leave a comment here explaining why you prefer a particular option! (or why the alternative is bad)

[raphaelbadia]

I voted for useExtracted because it sounds good to me, I understand clearly what it means.
I feel like I would forget the name useInline, and I'd be like "What's the function called again" ?

[jurerotar]

This is a bit more on the hacky side, but how about adding the inline method to t directly?

import { useTranslations } from 'next-intl';

function InlineMessages() {
  const t = useTranslations();
  t.inline('Hello {name}', {name: 'Jane'});
}

T function signature is then either an invokable function or an object with this method. It doesn't address your third point though sadly :(

[amannn]

@raphaelbadia I can relate to that, yes!

@jurerotar Yep, theoretically also a possibility! However, next-intl currently also supports t.rich & t.markup and these will need to be supported for extracted messages too. I have a loose thought of getting rid of them in favor of a generic t function that would just return the right thing based on the arguments it receives, but it's still a bit further down the road—I wouldn't want it to block adoption of message extraction. So for the time being, message extraction should be compatible with those existing APIs.

[ceolinwill]

I don’t have a strong opinion, but useInline feels too vague since it could mean anything (not necessarily an inline translation). I’d probably prefer something like useInlineTranslation because it makes the purpose clearer.

[priyajeet]

Having the word Translation in the hook name will make the hook more self documented imo. Otherwise people might have to proxy hook to make it more readable. useInline and useExtracted don't really mean much imo unless you look at where its being imported from which may be collapsed away in github reviews.

[amannn]

Some thoughts on rich text formatting from @niieani:

As far as rich text, there's a way to do it while using string literals. I might have not mentioned that in my talk, but we had a solution, which was something like this:

const Bold = ({children}) => <b>{children}</b>
t(`This is <Bold>${userName}</Bold>.`, { components: { Bold } })

basically, we parse the string literal with the DOMParser and construct a React Array by wrapping any components with the components passed in as the component resolvers in the options passed to t function
this also works with nesting
and we statically analyze the strings during compilation to ensure that all the tags are correct and closed
this also means you can insert any component inside of any string, not just ones that wrap text (if that's something you needed) and is easy to understand by many translation tools.

I think it's an interesting approach, somewhere in the middle of using direct concatenation and using arguments in ICU strings. Kind of a hybrid solution in contrast to what the RFC currently discusses.

[amannn]

A first release is out in [email protected]! 🎉

Learn more:

• Blog post
• X post
• Bluesky post

[ceolinwill]

Thanks again for working on this. I wanted to share some initial feedback:

1. Source string in PO files

Right now, the msgid in PO files uses a random ID like Ju9oB+. This makes it harder to translate, since we have to check the source file to understand what each key refers to.

In other frameworks using Gettext (like Phoenix), the msgid stores the actual source string. For example:

msgid "Create an account"
msgstr ""

It would be great to have an option for this behavior, or at least include the source string as a comment above each msgid.

2. Deterministic compilation

Currently, every next build changes the order of items in the PO files, even when nothing in the code has changed. I tested this a few times and it happens consistently every time.

Ideally, the output should be deterministic and only update when translations are actually added, modified, or removed.

[ceolinwill]

@amannn Awesome, thanks! It’s mostly fixed. There’s still one edge case where the order changes if a locale has missing translations. For example, it worked fine for en.po, but pt.po and es.po (which had missing entries) still showed diffs.

Once I added the missing translations, it became deterministic. Probably not a big deal since that won’t happen often, but figured I’d mention it.

[amannn]

Hmm, that doesn't sound right. Let me have another look, I've probably missed something. I'll get back to you!

[amannn]

Should be fixed with this: #2103 (comment)

[ceolinwill]

@amannn Quick update. I might have run into another issue, but I’m not fully confident because it’s hard to reproduce.

A few times, all translations in a locale were replaced with empty strings. I first saw it while testing the canary build when pt.po translations suddenly got wiped, but I couldn’t reproduce it and assumed I had deleted that file by mistake and it had to be rebuilt.

However, now it happened twice on my branch using 4.5.2. I’ve probably run the build 20+ times and only saw this happen 3 times, so I don’t have a reliable repro. Just mentioning it in case it helps you spot something. This happened twice with my pt.po file and once with es.po, never with the source en.po file.

[amannn]

Thanks, I'll check if I can find something suspicious that could cause this. I'll follow up here!

[ceolinwill]

Something else I just noticed:

Fallback for untranslated strings

Right now, untranslated strings render as empty. It would be great if they could fall back to the default locale.

For example, if a string isn’t yet translated to es, it could display the default version (eg en) instead of an empty value.

[amannn]

You can already do that in i18n/request.ts:

import {getRequestConfig} from 'next-intl/server';
 
export default getRequestConfig(async () => {
  const userLocale = 'es';
  const defaultLocale = 'en';

  const userMessages = (await import(`../../messages/${userLocale}.json`)).default;
  const defaultMessages = (await import(`../../messages/${defaultLocale}.json`)).default;
  const messages = {...defaultMessages, ...userMessages};

  return {
    messages,
    locale
  };
});

You can replace .json with .po depending on the formatter that you're using, but since this will import the messages as plain JS objects, the pattern is exactly the same.

In theory, we could display the source text in development as a fallback, but this would suddenly vanish once you build for production. So my current understanding is that it might be clearer if we let users do this themselves in either case, to have more flexibility and to avoid surprises.

Does that make sense?

[ceolinwill]

Yeah, that's a good idea. Thanks!

[bennajah]

This works only when the extracted messages feature is not used.

When using the feature, for example with the default locale set to en, we have:

en.json

{
   "AAA": "text1",
   "BBB": "text2",
}

de.json

{
   "AAA": "",
   "BBB": "",
}

When calling useExtracted() or await getExtracted() on untranslated pages, only empty strings are shown — because the untranslated message files are automatically generated with empty string values.
Even if you manually clear or delete these files, they get recreated automatically.

[amannn]

Right, but it's really up to you to merge however you like, e.g. not using entries with empty messages. Extracting the empty strings to target locales is something that happens by design, which should act as a call to action in your git diffs to insert missing translations. But you can also do locales: ['en'] if you don't want to extract to target locales. Or define a custom formatter in the future if you have more specific requirements.

[bennajah]

Is the package tree-shakeable and does it bundle only the messages used by the current page — similar to how @inlang/paraglide-sveltekit works for SvelteKit?

[amannn]

Last time I checked, paraglide used per-message splitting. This is in contrast to next-intl, which uses per-locale splitting.

The former can help with tree shaking if you support a few locales, but the problem is that it will bundle all variants for all languages that you support. E.g. the Ethereum website localizes to 69 languages, therefore for projects of this size this is just not really an option to begin with.

With per-locale splitting, we need to solve the problem the other way round. Today, you can optimize manually if you like, but automatic tree-shaking is planned for the future.

The package itself is of course tree-shakeable (it's ESM-only) and will only bundle the features you really use.

Hope that helps!

[c0nsoleg]

Should it work with monorepo? Seems like message aren't picked up from packages at build or dev.

[amannn]

Monorepos are supported, yes. The docs are a bit sparse in regard to this though, I'm planning to include more.

See also: https://x.com/jamannnnnn/status/1987163883165860145

But did you encounter a bug? If so, can you share a reproduction?

[bennajah]

i dont have src folder and i want extract from root folder

so when use

srcPath: "./",

instead of

srcPath: ["./actions", "./app", "./components", "./lib", "./schemas"],

messages not extracted

[amannn]

Thanks, I'll look into this! I think it's likely happening due to a guard against traversing your node_modules missing, therefore the initial scan doesn't complete (or very late). I'll share an update here once this is fixed.

In the meantime, you can use an array of explicit folder names.

[amannn]

@bennajah This should be fixed in [email protected]!

[priyajeet]

Will this work if t is passed into a plain old function?

[amannn]

Only statically analyzable calls like t('Hello!') are supported, anything dynamic like t(key) will print an error. I'll add some docs for this that covers how to write code in a statically analyzable way, covering common patterns.

Can you share your use case why you'd want to pass t into a function as a parameter?

[priyajeet]

Specifically for code organization. Say I want to translate based on an error code, I may have a function that takes the t function and code and has a gazillion switch case statements returning a different string based on code. And then I show this string to the user via a banner, say toast(). Likewise this function can be also used somewhere else. Now, one can make the function a hook and then useExtracted can be used in it, but then that is not re-usable in non-react parts and testing also becomes hook based as opposed to a simple plain old function based. The current t from useTranslations() seems to work when passed around (with some TS type annoyance), but it doesn't do any extraction so that was not an issue.

[bennajah]

Could you make locales accept a typed Locale? I'm getting a TypeScript error as shown in the screenshot below.
It’s not ideal to hardcode locales here since I’ve defined a reusable locales constant in i18n/config.ts

[amannn]

@bennajah This should be fixed in [email protected]!

[bmichotte]

We use next-intl on all our websites with a dashboard that allows our customers to directly modify translations if they wish.

Our workflow is as follows: we load the translations from the JSON, then we retrieve what comes from the database.

We merge everything and send it.

    const json = (await import(`../../messages/${locale}.json`)).default
    const flattened = flatten(json) as Record<string, string>

    const url = new URL(`${publicEnv.NEXT_PUBLIC_BASE_URL}/api/i18n`)
    url.searchParams.set('locale', locale)
    const data = await fetch(url.toString())
        .then(res => res.json())
        .catch(() => ({}))

    const messages = {
        ...flattened,
        ...data,
    }

    return {
        locale,
        messages: {
            ...(unflatten(messages) as Record<string, unknown>),
        },
    }

With the system as developed here, our version is no longer possible because the keys change. However, if the keys do not change, then we can use the feature.

Is it possible that the keys are the text as encoded?

Something like :

const t = useExtracted('namespace')

return <span>{t('Hello Github')}</span>

conversion :

{
  "namespace": {
      "Hello Github": "Hello Github"
   }
}

which would allow us to change the value in database while keeping the key ?

Edit: Looks like I'm not the only one wanting this feature :D #2036 (comment)

[bmichotte]

Ok, I gave it a shot...

Looks like we're good to go :)

Last thing I have to check if it's I can easily adapt my scripts to use the .po files instead of the .json

[amannn]

Nice! I‘ve implemented a .po parser for next-intl while working on the feature since I didn’t find the existing ones to be that good. I‘m planning to open-source it soon as a standalone library in case that’s helpful to you!

[amannn]

@bmichotte It's available here now: po-parser.

The next version of next-intl will depend on it and removes the internal implementation.

[bmichotte]

@amannn that's awesome.

I like that :)

Would you mind adding the original message as a comment on the .po files ?

Let's say

en.po

#: src/app/[locale]/(web)/_components/sidebar.tsx
msgctxt "Menu"
msgid "ATDyLP"
msgstr "New chat"

fr.po

#: src/app/[locale]/(web)/_components/sidebar.tsx
#| New chat
msgctxt "Menu"
msgid "ATDyLP"
msgstr ""

That would help when reviewing the files "manually"

[amannn]

Nice!

Re original message: I think there should be a reusable community adapter for this once custom formatters are supported: #2036 (reply in thread)

[bennajah]

When merge default messages with untranslated messages still show empty String

[amannn]

Please see #2036 (comment)

[bennajah]

getting this error in monorepo when using

import { getExtracted } from "@repo/i18n/server";

export default async function Page() {
  const t = await getExtracted();
  return (
    <h1>{t("title")}</h1>
  );
}

./apps/web/app/[locale]/page.tsx

Error evaluating Node.js code
ResolveMessage: Cannot find module 'next-intl/extractor/extractionLoader' from 'C:\Users\benna\dev\my-app\apps\web\.next\dev\build\chunks\[turbopack]_runtime.js'

[amannn]

Any chance you could share a small reproduction? You could start with https://github.com/amannn/next-intl-example-extracted and turn it into a monorepo that illustrates your use case.

[bennajah]

Any chance you could share a small reproduction? You could start with https://github.com/amannn/next-intl-example-extracted and turn it into a monorepo that illustrates your use case.

https://github.com/bennajah/next-intl-monorepo

[amannn]

I don't know, in your example I get errors about Bun not supporting source maps:

But other than that, I just now see that you've wrapped getExtracted into another library. That must not be done, only imports from next-intl are considered.

I'll provide docs about this and more generally also monorepos in the future (see also).

[bennajah]

@repo/i18n/server is a direct mirror of next-intl/server.
So the import is correct

You can see the implementation here:
https://github.com/bennajah/next-intl-monorepo/blob/main/packages%2Fi18n%2Fsrc%2Fserver.ts

[melkir]

Hello,
I’ve been using useExtracted for a week now, and my main downside is that updating the default locale requires manually finding the generated IDs to update translations in other languages. Often, I end up deleting the .next folder just to verify that all translations are correctly applied. Sometimes, for reasons I don’t fully understand, all the keys get wiped out.

On the positive side, being able to extract text directly from the code feels cleaner, no VSCode plugin to inline messages, just wrap the text with t function, very convenient.

At the very beginning, I spent a lot of time thinking about key naming and namespaces, but I often ended up duplicating the same translation across different namespaces or keys just to make it easier to locate within the project. Over time, I realized I actually prefer translating the text directly and using the code editor or the PO file to find where each translation resides. One approach I’ve seen in other projects, like Lingui, is to also include the line where the translation appears, which can be helpful.

[amannn]

updating the default locale requires manually finding the generated IDs to update translations in other language

I assume your use case is something like fixing a typo or tweaking a label slightly (while keeping translations)? But yes, I'd like to better support that use case in the future. I'm currently thinking about providing some kind of editor (maybe an extension for VSCode & friends), that allows to see all your translations next to each other and can sync back changes to your source locale into source code.

I end up deleting the .next folder just to verify that all translations are correctly applied

Is that a precaution related to the issue of wiping out translations? I'm looking into that, but deleting your .next folder should really not be necessary. Ideally, you should run next dev and translations are modified as needed while you're working on your app.

On the positive side, being able to extract text directly from the code feels cleaner, no VSCode plugin to inline messages, just wrap the text with t function, very convenient.

Nice, glad to hear! 🙌

One approach I’ve seen in other projects, like Lingui, is to also include the line where the translation appears, which can be helpful.

Are you using the .po formatter? next-intl should add these file references as well.

[JuliusGudni]

Is that a precaution related to the issue of wiping out translations? I'm looking into that, but deleting your .next folder should really not be necessary. Ideally, you should run next dev and translations are modified as needed while you're working on your app.

Approx half of the time, when adding new translations, the files don't get correctly updated unless restarting the dev server or removing the .next folder

[amannn]

Ok, that sounds very off. You mean both for your source as well as target locales?

[amannn]

Let's collect feedback about wiped-out messages here. I'm currently investigating the bug, but I haven't found the cause yet.

Can you explain in as much detail as you can what exactly you were doing when this happened to you? And can you give me all the details about your environment (OS, hardware, Next.js version, next-intl version, …). Also your config for next-intl in next.config.ts would be interesting and which locales you have in your messages folder.

A few additional questions:

1. As far as I understand, this happens only to target locales (not your source locale), is that correct?
2. Does it happen for all target locales or a specific one?
3. Am I understanding correctly that the values are reset to "", so the keys themselves are there?

Many thanks for your help, this is at the top of my list for useExtracted!

/cc @melkir @ceolinwill @JuliusGudni

[ceolinwill]

@amannn This just happened again when I was setting up this repo on a new MacBook. It happened when I ran pnpm build from the root directory (which uses Turborepo).

I have three translation files there: en.po, es.po, pt.po. Only es.po got wiped out.

This happened only the first time I ran pnpm build. I couldn't reproduce it again. One thing I realized is that this always happened when I was building multiple apps at the same time (using pnpm build with Turborepo). I don't know if it's just a coincidence since that's how I often run builds, though.

[JuliusGudni]

@amannn I was migrating a project from useTranslations to useExtracted. json files set up for useTranslations, and po files for useExtractions.
My process was following: Migrate one component or page to useExtracted, and wait for the other locale to refresh - once that was done I stopped the dev server (when editing target files with Poedit, something crashes in the dev server, which results in the target files only partially updating, or not at all until the dev server is restarted), and added the translations to the target file.
Every time when clicking "Needs work" for some translation in Poedit and starting the dev server, for a split second the nextjs browser tab returned with "fuzzy comments not suppported" before emptying all values in my "de.po" file.

Next.js: 16.0.3
next-intl: 4.5.5
MacOS Tahoe
Macbook Air M3 | Beefy hackintosh
Locales: "en.po" (source) and "de.po"

next.config.ts
`import type { NextConfig } from "next";
import createNextIntlPlugin from "next-intl/plugin";

const withNextIntl = createNextIntlPlugin({
experimental: {
srcPath: "./src",
extract: {
sourceLocale: "en",
},
messages: {
path: "./messages",
format: "po",
locales: "infer",
},
},
});

const nextConfig: NextConfig = {
reactCompiler: true,
experimental: {
turbopackFileSystemCacheForDev: true,
},
};

export default withNextIntl(nextConfig);
`

request.ts
`export const locales = ["de", "en", "fr"] as const;
export const defaultLocale: Locale = "de";

export default getRequestConfig(async () => {
const store = await cookies();
const candidate = store.get("locale")?.value;
const locale = hasLocale(locales, candidate) ? candidate : defaultLocale;

const jsonMessages = await import(../../messages/${locale}.json);
const poMessages = await import(../../messages/${locale}.po);

return {
locale,
messages: {
...jsonMessages.default,
...poMessages.default,
},
};
});
`

[amannn]

Thanks everyone for the feedback!

fuzzy comments not suppported

Ah yep, they're indeed not supported yet. I'll look into that.

I'll dig into the overall issue as well now, will share an update here once I have more!

[melkir]

This is the repository I’m currently working on:
https://github.com/animokikaku/guesthouseosaka

OS: macOS Sequoia 15.6.1
Hardware: MacBook Air M2

"next": "16.0.3",
"next-intl": "^4.5.5",

next.config.ts: https://github.com/animokikaku/guesthouseosaka/blob/main/next.config.ts

---

Current Translation Workflow

When changing the default locale (English):

1. Update the text in the source code, which modifies the msgid.
2. Search for missing translations in fr.po and ja.po (looking for msgstr "") and update them manually.

When updating a non-default locale:

1. Search for the existing translation text and update the corresponding entry in fr.po or ja.po.

---

Wiped-out messages

The only things I am certain is that it happens while I am developing with dev running and only on the locales that aren't the default one.

---

UX Problem With the Current Setup

The collaborator I’m working with is a native Japanese speaker, and they often ask me to treat Japanese as the source of truth. However:

• If I update the Japanese translation,
• I must also update the English translation,
• And when I update the English translation, next-intl wipes the Japanese entry,
• So I need to re-enter it manually.

This makes collaboration—especially through tools like Crowdin—much more difficult.

---

Considering Alternatives

To solve this, I'm thinking about:

• Switching back to useTranslations to have stable and predictable IDs, or
• Defining explicit translation IDs everywhere.

[LouisCuvelier]

useExtracted is a very good idea ! Thanks for that !

I've been experimenting with it, but I'm unsure if the behavior is correct: autocompletion isn't working anymore.

My expectation: if a message already exists somewhere (e.g., "Reload the page"), typing "Reload" should trigger an autocompletion suggestion. But it's not happening.

Question: Is this the expected behavior, or is there an issue with my setup?
Another question: createMessagesDeclaration with .po files is not working. Is support planned ?

For info :

• Turborepo monorepo
• "next-intl": "^4.5.5",
• "next": "^16.0.1",

Config :

// next.config.ts

const withNextIntl = createNextIntlPlugin({
  requestConfig: "./src/shared/i18n/request.tsx",
  experimental: {
    createMessagesDeclaration: "./src/shared/i18n/translations/fr.json",
    srcPath: "./src/app",
    extract: {
      sourceLocale: "fr",
    },
    messages: {
      format: "json",
      path: "./src/shared/i18n/translations",
      locales: "infer",
    },
  },
});

// request.tsx

export default getRequestConfig(async ({ requestLocale }) => {
  // This typically corresponds to the `[locale]` segment
  const requested = await requestLocale;

  // Ensure that a valid locale is used
  const locale = hasLocale(routing.locales, requested)
    ? requested
    : routing.defaultLocale;

  await loadZodLocale("fr");

  return {
    onError: onNextIntlError,
    timeZone: "Europe/Paris",
    locale,
    messages: {
      ...(await import(`./translations/${locale}.json`)).default,
    },
  };
});

// next-intl.d.ts

declare module "next-intl" {
  interface AppConfig {
    Locale: (typeof routing.locales)[number];
    Messages: messages; // Importing the emitted fr.d.json.ts
    Formats: typeof formats;
  }
}

[amannn]

Hey, thanks for the question!

autocompletion isn't working anymore

Yep, that's currently not implemented. The background is that this feature has significantly less relevance for useExtracted, since we don't need to ensure your source code correctly references available IDs. However, I can see that it could be interesting to make it easier to autocomplete existing entries (while also allowing new ones). I made a note of that, thanks for raising this!

createMessagesDeclaration with .po files is not working. Is support planned ?

It's not necessary, inline messages with useExtracted will automatically check for correct usage of arguments! :)

[LouisCuvelier]

Yep, that's currently not implemented. The background is that this feature has significantly less relevance for useExtracted, since we don't need to ensure your source code correctly references available IDs. However, I can see that it could be interesting to make it easier to autocomplete existing entries (while also allowing new ones). I made a note of that, thanks for raising this!

Thanks ! It would be really useful for consistency for common actions.

It's not necessary, inline messages with useExtracted will automatically check for correct usage of arguments! :)

So, this is not necessary anymore ?

declare module "next-intl" {
  interface AppConfig {
    Locale: (typeof routing.locales)[number];
    Messages: messages; // Importing the emitted fr.d.json.ts
    Formats: typeof formats;
  }
}

[amannn]

The Locale and Formats part is still relevant! Messages currently doesn't make a difference for useExtracted, but I've added your request to the list—I think it could be interesting. createMessagesDeclaration is definitely not needed.

[zziger]

Seems like having a newline character in the string passed to t leads to generation of a broken .po file:

t('Test string\nwith newline')

results in

msgid "J+/aas"
msgstr "Test string
with newline"

which I suppose is not allowed by the .po format, since that breaks some parsers I've tried

[amannn]

Ah yep, that sounds like a bug. I'll look into it!

[bmichotte]

I also found that this

<span>{t("I don't like \"this\"")}</span>

results in

msgctxt "SomeNamespace"
msgid "gys+7a"
msgstr "I don't like "this""

and outputs

<span>I don't like </span>

[amannn]

Great point, yes—I'll make sure there's corresponding encoding for all characters that could be problematic. Should have a fix out soon.

[zziger]

One more kinda-related question: Would it be possible to support literal string concatenation as long as there are no other types or dynamic values?

Something kind of a:

t('string' + 'otherString')

This is quite a common approach to split long strings over multiple lines in source, especially when dealing with newlines like

t('line1\n' +
  'line2')

[amannn]

Hmm, I see your point. The thing is that we might also support the other way round at some point, where a change to the source catalog updates source code. In this case, such concatenation might be lost. Or we'd have to consider a heuristic of producing this ourselves. Not sure yet. I think I'd wait a bit with this to get a more complete picture first.