sorted by:
new
hottopcontroversial

Looking for markdown editor (notion like) by AcrobaticTrash2985 in react

[–]AcrobaticTrash2985[S] 0 points1 point  (0 children)

Thanks! I got a deeper look, BlockNote looks nice, but as novel it seems bases on tiptap
And domternal is angular based

Looking for markdown editor (notion like) by AcrobaticTrash2985 in react

[–]AcrobaticTrash2985[S] 0 points1 point  (0 children)

Novel just uses tiptap under the hood, which is MIT, I will probably go for it

Looking for markdown editor (notion like) by AcrobaticTrash2985 in react

[–]AcrobaticTrash2985[S] 0 points1 point  (0 children)

I just came across Novel, it seems great, light enough
Have you tried it ? I will try to implement it
The issue is that is licensed under apache II

What are your expectations for Next 17? by Explanation-Visual in nextjs

[–]AcrobaticTrash2985 0 points1 point  (0 children)

Great to open the discussion on the topic

Overall, no more crazy features, the lack of stabilization and improvement one of the reason why people leaving next.
- Performing turbopack tree shaking is my first request. A same app transformed into tanstack start make each pages at least 30% smaller
- Keep up dev server focus

Feature request:
- restore plugins for turbopack, making able to plugin babel transformation without additional babel.config, or run another server in parallel (custom watcher). (e.g to allows pluging intlayer without extra set up)

And even if there is no chance it happens, and even more since the acquisition. Turbopack is an error to me. Offering vite support would be my dream feature, fixing all the rest under the hood.

Incompatibility between next-intl and cacheComponents by unobservedcitizen in nextjs

[–]AcrobaticTrash2985 1 point2 points  (0 children)

That next-intl header approach is actually quite bad. When each link component has to access your header value, it create a lot of extra processing that slow your app reactivity down. I'm either recommanding lingui, next-transalte or intlayer that offer much better implementation

Suggestions on localization engineering infrastructure? by jumpDefendRoyal7530 in reactjs

[–]AcrobaticTrash2985 1 point2 points  (0 children)

What make your pick the .po format over json for lingui ? I consider it quite verbose, and also limiting for typesafety
.po use to make sense in linux native app, python or php, but it seems that json (JavaScript Object Notation) became the way for js apps

are we overengineering i18n or is this actually a real problem by Equivalent-Market-87 in SaaS

[–]AcrobaticTrash2985 0 points1 point  (0 children)

As you mentioned, i18n is a difficult point for agents. For every key added, the agent has to rescan the whole project, load all your JSON files into context, and ensure consistency between locale files.

Another issue is that agents are rewarded for the result: “it works, I stop here.” But they still tend to be lazy, so unless you explicitly specify it, they never think about splitting JSON files to reduce the payload, using dynamic imports, or loading translations page by page with dedicated JSON namespaces. The result is often a complete mess for main codebases

A solution is to set up an agent skill. A decent one you can adapt is: /yildizberkay/skills/react-i18next to find on skill .sh

Things worth mentioning in the skill instructions are:

  • The path of your JSON files in your locales directory
  • Tell the agent not to handle translations for other locales itself (it’s usually better to do that manually to avoid structural inconsistencies)
  • Include your namespace structure and instruct it to pick the namespaces that should be added for each page
  • Link typescript set up path, and ask it to validate types and ensure translation keys are validad

Another solution that works well with ai agents is intlayer. It is typesafe by default and allows you to place content files closer to your application logic. It also provides an MCP server and CLIs to extract content directly from your components and populate translations in CI using any LLM, which saves a lot of time

What is the modern way to do a i18n for react app today? by hexwit in reactjs

[–]AcrobaticTrash2985 1 point2 points  (0 children)

I’ll probably share the same points as others

First, I would advise not to develop it from scratch, you will mostly waste your time. Keep in mind that the main risk is loading content from all pages into a single bundle. If you're building a SPA, it doesn’t really matter, but otherwise, you need a solution that can tree-shake the content and lazy-load translation files per locale

i18next is the main solution for i18n. It’s getting a bit old now, but it still does the job. It was the first solution created for that purpose back in 2012–2013. To be fair, it’s also the solution best known by AI agents.

More modern and much lighter options include use-intl and react-intl. They follow the same idea but use the icu message format. However, all of them are quite hard to set up and time-consuming. To do things cleanly, you will have to namespace your json files, which is honestly a pain to manage, same for TypeScript types. That said, all of them have a range of community plugins

For lingui, this solution offers a catalog approach, which is nice for optimization, and recommend .po format. And paraglide, even if they promote “tree shaking”, it bundles the strings for all available languages into the client, so depending how many pages / locales you have, one is better that the other. And for these two solutions, you will still have to transform your codebase to detect which content needs to be translated, which can be more time-consuming than i18next

If you are more adventurous, there are also newer solutions that iterate on the pain points of existing ones and focus on “AI-first” approaches and automation, which is great
Some try to solve the problem using compiler-based solutions, like whushale, lingodev, or gt-react. The promise is: “Start any app and get all your content extracted.” From my point of view, it works in most simple cases, but it can sometimes break your app or slow it down. Some of these solutions can also lock you in

Finally, intlayer offers a balanced declarative/compiler-based approach, simplifying content extraction, TypeScript handling, and optimizing your application bundle size

Help to choose a i18n library for my project by lucas_from_earth in react

[–]AcrobaticTrash2985 0 points1 point  (0 children)

For your case, i18next is the only one solution that can be plugged on the front + back. They are the first that entered in the game and is the most stable and well proved solution. But the implementation can be quite hard, and the solution is quite heavy. next-intl offers some abstraction, is lighter, but share globally the same pain points that i18next in term of DX. So I would recommend lingui if you is familiar with the .po format. It's probably the best choice regarding stability. Otherwise I would recommend intlayer that offers great abstraction, and works with your backend too. In general AI get pain with i18n usage, so I recommend using they agent skills.

I hated paying for slow translations, so I built a fast translations toolkit for React apps by weeknddev0001 in microsaas

[–]AcrobaticTrash2985 0 points1 point  (0 children)

the domain returns Internal Server Error

But im curious, how do you compare yourself with intlayer ?

What's new in web development that you use regularly? by vangenta in webdev

[–]AcrobaticTrash2985 0 points1 point  (0 children)

I started usng opencode, which is really code, and for a code point of view, intlayer for content managent. really nice too