Opral
paraglide-js preview feedback thread #1464
Replies: 9 comments 41 replies
-
Should paraglide enforce namespaces?Monorepos will run into the problem of shared projects. Importing from a non-namespaced path like // forbidden import because no namespace is set
import * as m from "@inlang/paraglide-js/messages"
// only allowed import schema
import * as m form "@inlang/paraglide-js/{namespace}/messages"Pros
Cons
Current behaviorThe compile command throws if two different projects are compiling into the same namespace which can be the default |
Beta Was this translation helpful? Give feedback.
-
|
@JonL1 Keep in mind that namespaces in paraglide and i18next are completely different. Namespaces in i18next "split" translation files into chunks, which paraglide does not have to do since we emit tree-shakable message function, which the bundler automatically (and much more precise!) chunks. Namespaces in paraglide refer to different inlang projects that you can compile into different "namespaces" to avoid two projects overwriting each other's message functions. What do you think about changing |
Beta Was this translation helpful? Give feedback.
-
|
Ah got it. Yeah. Maybe an alternative name to "namespace" will be less confusing. |
Beta Was this translation helpful? Give feedback.
-
|
Beta Was this translation helpful? Give feedback.
-
|
imo for now I am using just |
Beta Was this translation helpful? Give feedback.
-
|
@ZerdoX-x I agree. I will remove the requirement to define a name. Instead, I will implement a detection when two different projects compile into the same output directory to prevent unexpected behaviour. |
Beta Was this translation helpful? Give feedback.
-
Should a message function return a fallback?From https://discord.com/channels/897438559458430986/1163504297577812179/1163792775003766874 
|
Beta Was this translation helpful? Give feedback.
-
|
I would suggest to use apple approach to this. https://developer.apple.com/documentation/foundation/nsbundle/1417694-localizedstringforkey That is: return the key if translation not found. Would be also good if translations could be split into different files. (Key and table/file). Just same as in apple. In the runtime development and test I would suggest to generate at least warning. Better even write some output, which keys are missing - prepare json of misses. In test runtime - configurable crash. Why: linting checks statics. In runtime I need to localize error messages/codes returned by the server. So if I forget to localize some code/key. I want it to fail in test. The lib is great guys! One more thing. Since the tests usually run in one language. I would suggest to warn/crash/write missing key json in case if key is missing in any language translations - configurable. |
Beta Was this translation helpful? Give feedback.
-
|
Personally I would like see this configurable in |
Beta Was this translation helpful? Give feedback.
-
|
Fallback to a different (main) language is valuable. Yeah you should always have all language translations strings available for each supported language in an application/site, but real life is messier than that. Being able to fallback to a language (like the main one in your country) can be better than an empty string (or key name) or a dubious machine-translated one you're forced to accept just to avoid an empty string (or key name). |
Beta Was this translation helpful? Give feedback.
-
|
I follow the comments here since two months and it's really interesting that there is no common ground on how to do it in a single best way. If this is the case, we should again think about how the user would have the best experience, and which tooling we can introduce to make it real. For me as a user, a missing translation/message is something I don't want to have because it leads to a bad experience, where the answer could be that when using paraglide in a build step, we could offer an context-based AI machine translate. This does not fulfill the quality standards we want to have where every message is translated by a native speaker, but could fix the message existence problem. In bigger projects, the machine translate eventually ends to be paid feature so there has to be a way paraglide handles it without the help of a paid feature, where we could argue that fallback to the source language would be sufficient. That said, we could probably allow for more than one behavior, or a "escalation chain" on how this problem is tackled. |
Beta Was this translation helpful? Give feedback.
-
|
In the long run, it's going to be very valuable for all language modules ( Having a config for the fallback order seems overkill in most cases, but we could talk about it in the future.
|
Beta Was this translation helpful? Give feedback.
-
Better API name for
|
Beta Was this translation helpful? Give feedback.
-
|
The inlang Ecosystem uses the BCP 47 language tags to try to implement a standard. I hope this answers the question. :) |
Beta Was this translation helpful? Give feedback.
-
|
I'm sure this was discussed, but still I wonder why not |
Beta Was this translation helpful? Give feedback.
-
That indeed would explain it :) Thanks for the background info! |
Beta Was this translation helpful? Give feedback.
-
|
@buhodev @JonL1 as @jannesblobel mentioned we strive for interop. The current best practice on the web, used by HTML and JavaScript, are BCP-47 language tags. See https://en.wikipedia.org/wiki/IETF_language_tag. |
Beta Was this translation helpful? Give feedback.
-
|
Clear as water! |
Beta Was this translation helpful? Give feedback.
-
|
I've put my adaptation of an adapter into Gist (using these for the first time). Here's a link in case it's useful |
Beta Was this translation helpful? Give feedback.
-
|
When I'm working in the main |
Beta Was this translation helpful? Give feedback.
-
|
Ah, I see. Ideally, we can run a conditional along the lines of I am a bit reluctant to add cleanups and what not. The root cause is multiple calls of |
Beta Was this translation helpful? Give feedback.
-
|
I found https://vitejs.dev/guide/api-hmr.html#hot-data where we could store that if (browser && import.meta.hot.data.onSetLanguageTagAlreadyCalled === false){
onSetLanguageTag(() => {
// ...
})
import.meta.hot.data.onSetLanguageTagAlreadyCalled = true
} |
Beta Was this translation helpful? Give feedback.
-
|
I did the following and after the changes in the if (browser && (!import.meta.hot || !import.meta.hot.data.onSetLanguageTagAlreadyCalled)) {
onSetLanguageTag((newLanguageTag) => {
// ...
});
if (import.meta.hot) import.meta.hot.data.onSetLanguageTagAlreadyCalled = true;
} |
Beta Was this translation helpful? Give feedback.
-
|
Hm. Given the problems, it might be easiest not to throw if |
Beta Was this translation helpful? Give feedback.
-
|
Hm. I'll try to use the |
Beta Was this translation helpful? Give feedback.
-
|
Currently integrating
// lint-staged.config.js
export default {
"project.inlang.json": "npx @inlang/cli project validate",
};
For now that's all I am interested in. I just started working on integrating and now I'll migrate all my t10s from raw strings in components to a UPD:
Maybe we could create separate thread where we could discuss must-have features for our first adapters? Because for me it's not really related to the paraglide API itself and doesn't fit into the feedback thread. First things that come to mind is configuring: "persistence strategy": cookies, localStorage; opt-in routing support: translations for url part; probably adapter will require somewhat prop to know in which environment it would run: SSR? SSG? SPA? which will affect on it's behavior; where and how to get translation messages: are they located in some server and we need to |
Beta Was this translation helpful? Give feedback.
-
|
@ZerdoX-x Thank you for the elaborate feedback. PS I also replied to your feedback on Loom! :) 1. Break up translations into multiple files
Yes. You can use any storage format you'd like. For example, the JSON storage plugin https://inlang.com/m/ig84ng0o/plugin-inlang-json, which also reduces the clutter of the inlang message format plugin/is it easier to write translations manually.
Keep in mind that the source files are irrelevant for the application. The emitted message functions are automatically tree-shaking by your bundler of choice. The traditional reasons for translation file splitting are more or less redundant:
2. Improving the manual editing experience of the inlang-message-format plugin
Yes, we could. I am awaiting more feedback on the inlang message format plugin before we make heavy changes. At the moment, the plugins naively stores the AST which is hard to edit. 3. inlang project init command is gone
There was, and ... it made no sense. The starting points for inlang can vastly differ. Some people bring their own plugins, i18n libraries like i18next, or start with paraglide js. Acknowledging all different getting started points is impossible in one command. Instead, the different products in the inlang ecosystem are now responsible to provide a getting started guide/command. The paraglide-js prerelease.4 implemented an init command, specifically for paraglide-js :) 4. Calling the inlang CLI without
If you installed the I recommend using the lint command in staging to validate your translations as well. // lint-staged.config.js
export default {
"project.inlang.json": "inlang project validate",
};5. Other syntax formats You can use any syntax format you'd like via plugins. The inlang message format you used can be swapped out for any other plugin that defines
Incorrect, any (storage) plugin that is used automatically works with paraglide's compiler :) Hence, if you want Fluent syntax, build a fluent plugin and you are done :) That said, we should rather improve the inlang message format plugin to ensure that all features are supported.
Correct and incorrect. Paraglide supports what the inlang message AST supports which is heavily influenced by the upcoming JS standard MessageFormat 2.0. The AST's source is here. As you can see, nodes for FunctionReference and this Markup RFC is already in the backlog. Variants are already supported in the AST which will enable pluralization, a/b testing, gender, etc. but not supported throughout all products in the ecosystem (like paraglide or the web editor). Support for variants in paraglide will come in the next few months! We are focused on nailing the basics first. 6. A thread for the SvelteKit adapter
That is a good idea! I created this discussion #1564
Bundled by your bundler :) This is the beauty of paraglide-js. Optimizing how translations are fetched/imported is redundant. Hence, namespaces, splitting translations files, etc is all redundant. Messages are compiled into plain JS which the bundler automatically tree-shakes and optimizes. @ZerdoX-x Thank you for such elaborate feedback and the compliments. Building inlang is complex. The requirements and workflows of different teams vastly differ. Building an unopinionated ecosystem that accommodates those different teams takes a lot of effort. |
Beta Was this translation helpful? Give feedback.
-
|
Is there currently support for using paraglide together with a sveltekit adapter-static project? I get some wierd behaviour when trying to change language tag, it navigates to the correct page but removes the "/en/" part. |
Beta Was this translation helpful? Give feedback.
-
|
Is there a planned release date for a stable version? We are currently experiencing som troubles with our internationalisation library and would like to switch but only after it has had a 1.0 release. |
Beta Was this translation helpful? Give feedback.
-
|
you can consider paraglide almost stable, we're currently adding features & fixing edge cases + enable easier ootb support for more metaframeworks. cc @LorisSigrist is there an official ETA for "stable" paraglide? |
Beta Was this translation helpful? Give feedback.
-
|
Actually, the 1.0 checklist is pretty much done. We could consider launching 1.0 next week |
Beta Was this translation helpful? Give feedback.
-
|
Okey perfect thank you!
|
Beta Was this translation helpful? Give feedback.
-
|
Did you consider using constants for strings that don't have placeholders? There is no need to pass params in this situation and the code will be cleaner without (). |
Beta Was this translation helpful? Give feedback.
-
|
There might be a way to compress it down to a 1 byte difference with a tagged template literal. //reuseable helper
let s=a=>()=>a[0]
export const my_message = s`I'm some message`the above optimisation would save 3 bytes per string-only message at a cost of 17 bytes upfront. So it would be worth it starting at 6 messages. |
Beta Was this translation helpful? Give feedback.
-
|
I wasn't optimizing for bundle size but from a DX and performance standpoint. Imagine you use translation in a huge loop (like a big data grid for example). Variable would be so much better than calling the same function over and over again (maybe if the function always returns the same string V8 does some caching, but I'm not sure about that). And inconsistencies here don't create any problems since autocomplete will work. It would be even better since there would be a clearer division for regular strings and the ones that expect variables as input. |
Beta Was this translation helpful? Give feedback.
-
|
I worry how this would impact our ability to use the message-index ( As for the performance issues: All JS engines have an optimising compiler that quickly removes the extra cost of repeated function calls. I don't see this causing any measurable performance impact. |
Beta Was this translation helpful? Give feedback.
-
|
Among other reasons, we cannot use constants because of features like #1567. @LorisSigrist really good argumentation line. Push back against added complexity because of "nice to have" features. This request is even a great example of how a nice-to-have feature could have blocked a crucial feature like #1567. PS @stepanorda nothing wrong with your request! Thanks for asking :) |
Beta Was this translation helpful? Give feedback.
-
|
@samuelstroschein OK #1567 makes total sense. |
Beta Was this translation helpful? Give feedback.
-
Context
This discussion serves as feedback collection on the pre-release of paraglide js.
Use 👍 and 👎 to indicate whether a proposal should be adopted.
Things that are yet to be released
See issue list #1439
How to get started with the preview
Watch this 📺 video
Documentation
Example SvelteKit project
Example SvelteKit i18n routing project
Beta Was this translation helpful? Give feedback.
All reactions