-
Notifications
You must be signed in to change notification settings - Fork 3.3k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add internationalization configuration to the front-end #2149
base: main
Are you sure you want to change the base?
Conversation
…glish, Portuguese, and Chinese.
The latest updates on your projects. Learn more about Vercel for Git ↗︎
|
This is so good, @jackiemoo ! |
Hi ogabrielluiz @ogabrielluiz , Thanks for your response. Could you please let me know if there are plans to support internationalization? I'd be happy to help if needed. Thanks! |
I am very interested in your work. If this is reflected in the main source and the structure is established, we will provide a Korean translation. |
Hey @jackiemoo This PR #2260 adds a very similar implementation. I think they merged this PR with them, I'm not sure. |
Hi @ogabrielluiz , |
Hey @jackiemoo We are going to prioritize this PR as this was the first one to be created. Please, let me know what are your plans and what else we need to merge it. |
Hi @ogabrielluiz , Thanks for your reply. 1.Finalizing the Basic Configuration: 2.Automatic Language Detection: 3.Adding More Languages: 4.Documentation: If there are any specific areas or features you think should be prioritized or if there are any blockers that need attention, please let me know. I'd be happy to collaborate closely to ensure a smooth and efficient integration of i18n. |
That's a very good plan. What do you say we create an issue with all the tasks required for this and we start with a basic implementation that simply makes langflow continue to work as is but with the i18n in place? That way we can make smaller improvements. |
Hey dudes, I think translating UI elements is great from an accessibility perspective. However, most use cases involve repetitive use of components. How about a design where users can suggest translations for components available in the LangFlow store at the component level? The original proposers of the components could then accept these suggestions. It sounds like it could be a challenging journey, but isn't there a good way to achieve this? |
In Korea, where I am from, Naver, which is like the Google of Korea, has implemented a similar concept by creating a structure where users can directly translate and share specific webcomics. |
We can do that for sure but it will require quite a bit of restructuring of the database |
Yes, I might have been too enthusiastic. It seems like it would require a massive investment of resources, so it might not be a priority right now. I'll keep it in mind and propose it again later. |
Hi @ogabrielluiz , Creating an issue with all the tasks required is a good idea. Here's how I propose we proceed: 1.Create an Issue for i18n Implementation: Outline the overall plan and break it down into smaller tasks. 2.Basic Implementation: Start with a basic i18n setup that ensures Langflow continues to work as it currently does. 3.Task Breakdown:
By taking these steps, we can ensure a smooth integration of i18n while making incremental improvements. If there's anything specific you think should be added or adjusted. Next step, we can go ahead and create the issue with these details. |
Add internationalization configuration to the front-end, including English, Portuguese, and Chinese.