-
Notifications
You must be signed in to change notification settings - Fork 154
Internationalization #66
Comments
Hey @joshwcomeau , I'd love to help out with this project and this seems like a great starter issue. That's just my 2 cents though, would love to hear your thoughts! |
It would make more sense to detect the user's preferred languages, I think those should be in |
Would it not be sufficient to use the language and locale set in the operating system? I don't commonly see native apps have their own language selector. React-intl/FormatJS seems like a solid solution, and it's good to start these things early on when there aren't too many hard coded strings all over the place. Since this application is going to be geared towards lightly technical users, who might have great enthusiasm to help, but not necessarily the confidence yet to contribute via GitHub, I think it would be good to start the language files from the beginning in such a way that they can be used with a translation service like transifex later on. Not a big issue though, since e.g. transifex supports plain json with key:message pairs using the ICU rules also used with FormatJS. I can extract the strings from the app and do the german translations. I can also look into detecting the system language and locale and setting up react-intl (though thats probably quite a large task). As a user of a "en_DE" locale I am also a nice edge case myself. |
Thanks for the feedback y'all! Excited to see so much enthusiasm around this issue :D Yeah, I should really check how other apps do this. Using the OS language seems like the best idea (the best UI is no UI!), with maybe an override in the application menu if it's deemed necessary. I'm unfamiliar with transifex, but agree a service might be nice to encourage translations from folks not familiar with Git!
Awesome 👍 |
I would love to help out too. I'm on a Windows machine so I can test/integrate OS language detection and also I'm "tr_TR" local. I can help to translate strings to Turkish. I have worked with i18next before a little bit. It has a library for language detection for electron (i18next-electron-language-detector) which can be helpful. I think its a good library to consider. |
@joshwcomeau If we plan on supporting multiple languages in our documentation, I think we should add some way to add the different languages within our repo (instead of having users host their own versions). That way we have ultimate control over the structure/consistency. Maybe a docs repo is best suited? WDYT? I'm |
Yeah, so I agree with this in theory :) I think the reason the Chinese version is internationally hosted is because it was the easiest way to support it. A more polished solution probably would be to have a That said, I'm not sure the project is mature enough for it to be worth the hassle... Once we have multiple languages, we'll need people committed to keeping those languages up to date, so we'd probably need to have some sort of external tool. Once the english docs are updated, we'd need to broadcast the fact that other languages need to be updated as well, have people be able to "claim" a language update... Working with i18n at work (Khan Academy is available in dozens of languages) shows how much administrative overhead there can be. So yeah, I totally agree that this could be much better, but wonder if maybe we should wait until the product is in a state of less churn to get it done? |
(also, for in-product i18n... I feel like this is slightly more manageable, since it works on a per-string basis. The worst case is occasional english slips through, which is far from ideal but also means that the overall product is still workable, since folks can just google the strings they don't understand... with outdated docs, it feels much more dangerous/frustrating) |
re: all of your points are very accurate, it is a lot of overhead, and quite possibly too early in the project's life for this kind of thing. Maybe we can leave this open for the future, but not worry too much about it now? EDIT: To go further, especially considering the age of the project, it might be "biting off more than we can chew" in regards to trying to do all the things. It could be just a "help wanted" if someone wants to pick it up, like you suggested originally in this issue.
+1 to this, having an updated English version/string is infinitely more useful than an outdated version in their language. |
Hi all, the issue looks very interesting to me. I have some experience with i18n and have used react-intl in my own projects. Also it would be great for me to take this as one of my first open source contributions. If no one else is currently working on it, I'm planning to make a fork and try to implement it these days. It might take a period of time considering the project size and the change of code structure. I'll try to add react-intl to the UI code and copy all the English strings to a JSON. The suggestion of taking the OS language sounds like a good starting point, although someone might want to add a language selection feature later. Besides, as a native Chinese speaker, I'd be happy to provide a Chinese translation if time permits. I have a friend to collaborate with me on these updates. Welcome to join us if you are also interested! |
hi @zianke, sounds great. Before you start, could you please compare Would be awesome to see the same for To the structure of the translations: Loading of the locale |
Hi @AWolf81 , thanks for your demo. We've also created a simple codesandbox demo for Although |
Cool, thanks. Yes, the demo helped and I think it's OK to use if you prefer it. Just some points I think would be good to have:
Please have a look in this codesandbox and for flow typing the following post will help. For the automatic language picking we could use The UI language switcher will be in app settings modal. I would also add a language switching menu item to ApplicationMenu so it's easier to switch between languages during development. If you need any help please let me know. If you like, I could add the application menu item & the |
Thanks, @AWolf81 . The message descriptor works. For the file structure of I agree that we'll need a language switcher before enabling i18n in the real UI. Otherwise Chinese users, for example, might find it troublesome if they are not able to switch back to English. But for now, we can test |
@zianke, yes, you're right and a good idea to see how many messages we have and if it is getting a large file we can refactor/split to multiple files. OK, I've started the app menu and reducer - it is ready and you can merge that into your branch to replace the hard coded value. You can find the menu item & reducer in branch i18n-app-menu-item. I think it's already usable - just the position of the menu item could change. At the moment, it is in The state you need for your localization is in |
@zianke how is the status of this? Have you made progress? |
Hi @AWolf81 , you can see our current progress here. We (I and @llllish) have listed all the message descriptors (excluding those hardcoded strings in non-component javascript code, such as We've also created an intl demo on the IntroScreen, so you can try to open this screen and switch the language to Chinese. Our approach is adding a |
Guppy's goal is to remove barriers for beginners to learn how to do modern web development. One huge barrier is that tools like create-react-app are only available in English, and many aspiring web developers don't speak English!
It would be awesome to get i18n support in Guppy. Unfortunately, it's also a huge amount of effort, and not one I foresee having time to develop. If folks are interested in contributing, the first step is to add i18n support to the application. One upside to building a desktop app is that small sizes aren't so critical, so we could probably get away with a pretty minimal solution:
/copy/en.js
or similarCurrent status (WIP see branch
feature-i18n
)The text was updated successfully, but these errors were encountered: