Open Kitenite opened 1 day ago
Hi @Kitenite can I work on this issue ?
@Kitenite would you like something like that for this new feature ?
@Kitenite would you like something like that for this new feature ?
This would likely be set in the user settings page as the user would only need to access it once. 🌐
We can add a line for Language with a dropdown to select the language in the Settings page.
This would likely be set in the user settings page as the user would only need to access it once. 🌐
@drfarrell @alexandreantunesmnds it should be very easy to get to so I'm more in favor of having it on top but I could be wrong. Because you may accidentally toggle a language and need to revert easily.
This is also going to be complex engineering-wise. I would really like if there's a low effort way we can support translation earlier on such as adding automated translation. The more popular way is to actually wrap text in internationalization but it's going to take effort to maintain. https://github.com/i18next/react-i18next
@alexandreantunesmnds what are your thoughts on the correct approach moving forward?
@drfarrell @Kitenite I can place the language selector in the user settings as suggested. However, I’m not entirely sure where the user settings section is located in the app—could you provide some guidance on this?
Regarding the technical approach, I’ve started by implementing react-i18next, as it seemed like the most structured way to manage translations. I’m less familiar with how an automated translation approach would work here, so I thought this would be the best starting point. Let me know if you have any specific ideas for handling automated translation or if you’d like me to continue with react-i18next.
@alexandreantunesmnds , the settings can be accessed be going out of the project view. I just realized that this was not accisible in dev mode. It is now as of https://github.com/onlook-dev/onlook/pull/754
react-i18next
sounds like the right approach. What are your thoughts on making this maintainable and low foot-print? Seems like we'd have to wrap each of our existing string and extend support for any subsequent string?
@alexandreantunesmnds , I do want to note that this is far out on the roadmap since it will slow down development significantly. So even if we have the infrastructure in place, I don't think we will add language support right away. Just FYI since you're already spending time on this and I don't want you to feel that it'll go to waste.
Describe the feature
Requested languages: