Is it possible to have multiple messges files for a language?

[Narigo]

I'm currently evaluating inlang and ParaglideJS for my future projects. In component based frameworks, I'd like to have everything related to a component in the same folder. Is it possible to set this up with the messages somehow?

Basically, if I delete a folder of a component, it should delete all related stuff - so I'd like to be able to put the messages JSON files in the folder for the component if it needs some texts on it.

I have read about namespaces, but I wouldn't even need this: I would be fine with this just picking up all messages-{lang}.json files in all subfolders and merging them together under the hood...

I've seen https://inlang.com/m/ig84ng0o/plugin-inlang-json#settings but the pathPattern doesn't allow for example ./src/components/**/_messages/{languageTag}.json because the ** are not interpreted as globs.

What I'd like to have:

/src
  /components
    /button
      /_messages
        /de.json
        /en.json
    /dropdown
      /_messages
        /de.json
        /en.json
    /bigger-component
      /_messages
        /de.json
        /en.json
      /sub-component
        /_messages
          /de.json
          /en.json

Is there a way to be able to do this without having to hardcode all components / their messages paths?

In SvelteKit, I would probably like to have a "per route" messages as well...

Thanks!

[Narigo]

Oh and I should probably add that even if I use the mentioned configuration from the link, something like this:

	"plugin.inlang.json": {
		"pathPattern": {
			"base64": "./src/routes/base64/_messages/{languageTag}.json",
			"general": "./messages/{languageTag}.json"
		}
	},

I receive an error saying:

Error: Cannot compile message with ID "base64:encoded".

The message is not a valid JavaScript variable name. Please choose a different ID.

So I assume multiple files per language are not there at all?

[samuelstroschein]

You can but the JSON plugin imports namespaces with : which is invalid for Paraglide JS. Use the message format plugin which works out of the box with Paraglide https://inlang.com/m/reootnfj/plugin-inlang-messageFormat#pathpattern

[samuelstroschein]

You could implement a plugin that uses globs or make a PR to this plugin and use node's fs.glob function.

Why do you want to to split the messages per component?

The only technical reasons why historically this has been done is to manually tree-shake. That is not needed with Paraglide JS. Good practice is to not optimize the structure of the message files at all. Everyone on the team needs to follow the same rules even across an org e.g. designers, translators, auditors.

[samuelstroschein]

I see. Before I give a recommendation, how do translators/auditors/designers interact with your translations?

The more namespacing and splitting of translation files you introduce (especially if designed for developers), the harder the hand-off step to a translation agency, translator, designer, auditor, etc will get

[Narigo]

I'm doing the evaluation basically myself, so I can't really say what would be the best way here. Let me try to explain where I'm coming from:

I did work with an agency in the past where we had a basic handover process, basically it was us generating the IDs we need to have translated into either a tool or a Google Sheet. We'd then have the different translators generate the texts in their language, seeing how others translated texts as well. This helped the ones doing translation later to better find out about the context of a word if they spoke multiple languages. But ultimately, we received all the translations, generated the page with the appropriate languages and let them review it on the page.

There were multiple problems with this approach:

1. They weren't really able to see what ID was used for what text. They could infer a lot by the default language we provided and the other languages which were translated earlier, but you could never be sure.
2. This made us re-use IDs for the same text multiple times. In the default language, there might be just one word that works for both contexts, but another language may tell us "it would be better to write something different on that other button here, but we can't". So basically having to create two IDs, default language having the same text twice in it and other languages being able to change it causes a loop with all translators again.
3. Changes to the page / app didn't really update the IDs anymore. If a section got removed, people still translated that part, because the IDs were still in this other tool (you don't want to throw anything away that you can't get back again).

It feels to me that these issues mainly come from having the translations split up from the code quite a bit. So when seeing this here having a Figma plugin, potentially making this work on components instead of "the whole application", I was very intrigued and thought this could be the solution I'm looking for: You can translate component by component and have a lot less issues when updating / having to update something.

I believe with some kind of namespacing (in my case this could basically be a file/folder name), this would be achievable to script (the namespace would ensure to update the specific file/folder, when the translation changes).

Does this context help...? 😅

Btw, thanks a lot for taking the time to read this and sharing your thoughts!

[samuelstroschein]

The context helps.

I understand that you thought that coupling translations with the component (co-location in code) made the translation process easier because it provides more context.

The thing I do not understand is why the co-location benefits translators?

For developers, Sherlock seems to make co-location benefits redundant. As a dev, you see the translation directly in the component. No matter where the translation is saved.

[Narigo]

Well, while I do think knowing which texts are for what component could help translators, it's not the main issue I have with the messages not being coupled. The bigger problem for me would be that if we remove a component or a part of the page / app / whatever, removing the existing translations for those parts becomes harder if they are not co-located in the code.

If a component is removed (e.g. a feature gets replaced by something else), there is no need to keep the old translations around - but it's hard to see which translations are actually still in use. I guess using Parrot for translating would help for that, but we may still introduce "dead code" in terms of translated messages which are not used anymore. Or is there a way to find out which functions will be tree-shaken away and it's going to be easy to remove them from the JSON at some point?

Slightly off-topic: If I, as a developer, want to introduce new texts, I can see the default language with Sherlock, but I can't easily jump to the definition of the text and change it - or did I just not find this function?

Totally off-topic: The message format plugin says it allows multiple paths, so you could overwrite parts of the default messages - this doesn't seem to work for me, I receive these messages when using https://cdn.jsdelivr.net/npm/@inlang/plugin-message-format@3/dist/index.js:

WARN No messages found - Skipping compilation

ERROR An error occured in loadMessages() caused by TypeError: a.plugin.inlang.messageFormat.pathPattern.replace is not a function.

[samuelstroschein]

The bigger problem for me would be that if we remove a component or a part of the page / app / whatever, removing the existing translations for those parts becomes harder if they are not co-located in the code.

This is solved by opral/inlang-paraglide-js#219.

To my point: You seem to optimize the splitting stuff for scenarios that inlang or related tooling eliminates. The complexity you introduce with splitting, namespacing, etc. is high, even though it might seem easier right now.

My recommendation is to either a) make a PR to adjust he message format to support your use case or b) don't give a damn about the translation files and incrementally adopt tooling that makes your life easier without the complexity cost you are about to introduce

---

I can see the default language with Sherlock, but I can't easily jump to the definition of the text and change it - or did I just not find this function?

You can hover over the message and edit it. At least that's what should happen. cc @felixhaeberle (building sherlock)

Totally off-topic: The message format plugin says it allows multiple paths, so you could overwrite parts of the default messages - this doesn't seem to work for me, I receive these messages when using https://cdn.jsdelivr.net/npm/@inlang/plugin-message-format@3/dist/index.js:

Please create a reproduction and an issue. PR is very welcome!