monorepo
monorepo copied to clipboard
opral
rfc-001-core-architecture
Hi @samuelstroschein, very detailed write-down 👏. Here are some comments on the points of th RFC:
Human Language Syntax
I would choose Proposal A, if it supports already > 95% of all use-cases (parameters, plural-rules, formatting, gender-rules, combinations). I cannot imagine that it will have fewer features than the current version of fluent. Maybe they could get rid of the "Terms".
SDK
I would advise against creating your own SDK 😉. Supporting mutiple features, multiple frameworks, CSR & SSR, CJS vs ESM and other things will take a lot of effort. Also convincing a team to use a different SDK is not that trivial. There will probably be not that many teams that will switch to a new SDK for a running project. Making it possible to add inlang on top of the current architecture would be a smart decision.
Dev tools
A developer should be able to check if something is wrong with the translations. Missing keys, missing/wrong params in messages, invalid keys, invalid message syntax and other possible errors should be able to checked by running a single command in the project.
Editor
If no server is involved, each translator would need a GitHub (or other platform) account with access to the full repository. This could have some security implications if the source code of a private repo would be shared with external translators. If it is running on a server, the git acccess could be hidden to translators and an inlang-bot (with the TOKEN of a developer of that project) would then commit the changes to the repository.
CI/CD
We use this process in a project and it feels great. Not having to manually import new translations, updating messages, looking for errors in those messages feels liberating. A daily process imports the translations automatically, CI checks if the format is correct and then creates a PR and merges the PR. Coming from a project where we had to do this boring and time-consuming process manually every few weeks I cannot imagine to do i18n without CI/CD anymore.
The Editor should already have some checks in place to instantly give feedback to a translator.
Architecture
1. How are messages stored?
I think the development team should be able to decide what message format they want the files stored in the repo. If they don't want to use the Editor to change something, they should be able to do it in a normal text-editor. The read write operations will anyhow need to transform it to an AST, then it is not important to inlang in what format the messages are stored on disk.
2. How is inlang configured?
The JS config file with the read and write methods sound good. I think you'll also have to think about different actions a translator could do inside the Editor (e.g. add/remove/change a whole locale). It makes sense if the write function knows what type of action was performed in order to be able to pick the correct "write" action and maybe also to trigger a different workflow depending on the action (e.g. create the PR only when the translator clicks on "submit" at the end of his editing session).
That's it. I hope you'll find my feedback useful.
@ivanhofer as always, thank you very much for your feedback.
I would advise against creating your own SDK 😉.
Your SDK is among the reasons why we went back to the drawing board to support a variety of SDKs.
If no server is involved, each translator would need a GitHub (or other platform) account with access to the full repository. This could have some security implications if the source code of a private repo would be shared with external translators. If it is running on a server, the git acccess could be hidden to translators and an inlang-bot (with the TOKEN of a developer of that project) would then commit the changes to the repository.
Indeed. I view that as a good thing for now. In the future, some auth abstractions could be built if desired.
I take from your remarks that inlang is headed in the right direction?
I take from your remarks that inlang is headed in the right direction?
Everything you have described above aligns with the long-term-goals of typesafe-i18n, so yes, I think you are heading in the right direction ;)
I'm still unsure about the client-only editor, but I don't know that much in that specific area ^^. I am curious to see the result.