-
-
Notifications
You must be signed in to change notification settings - Fork 259
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
Make Bridge Troll I18n compatilble #404
Comments
I think that having Bridge Troll available in all the languages that we have curriculums available in is a good idea, but it's a huge undertaking for a large Rails app that essentially has a single developer maintaining it. The RailsBridge curriculum has been translated to Spanish and Chinese for a while, and while I agree that it'd be better for the groups using those curricula to use Bridge Troll than Eventbrite or Meetup, so far having them use other software that's already in multiple languages has been a better use of our limited resources. I think we need to get more maintainers on Bridge Troll before taking on anything of this size. |
Would it be worthwhile asking people who'd be interested in taking on this as a group project? I would and I know @anymoto would as well. There must be others? |
@lilliealbert is it a question of doing the project or maintaining it once it is complete? I think the code is straightforward, just time consuming to move the text into the localization files and then translate. Once it is done are you worried that it will be hard to maintain the code? or maintain the translations? (for the latter, I think it is easy to set up that it will default to one language if translations are missing. In short: if someone were to do this, are you and @tjgrathwell open to accepting the PR... or do we need to plan for additional stuff before doing something like this? |
@ultrasaurus Mostly maintaining the translations, although the work of actually localizing the app is certainly a significant undertaking. To break it down, we could start by just localizing the attendee-facing pages, and then slowly work through all the organizer views. After the initial translation (which will be a big chunk of translating) I don't expect it'll be that often that we need more translations, but we'll definitely need ongoing help, forever. I'm worried that without that, we'll get into a state where adding a new feature is blocked by not having a translation, or having a terrible translation that we made via Google, or just showing up in English. (Having to find someone new to do translations every time we add a feature or change some copy sounds terrible, so having people who want to help on an ongoing basis would be much better.) I also would like to discuss a bit which strategy we'll use for determining which language to show a person — is this a setting that people set on sign up, that we then include in every URL? Meetup, for instance, allows you to pick your language on the settings page or via a drop down if you're not logged in. The Rails guide for internationalization has some recommendations around setting & passing the locale, but it doesn't look like there's a single preferred way to do this. |
I would like to propose that we make Bridge Troll I18n compatible so we can have internationalization. Not only the language in the UI but also date/time format can be a barrier for people who's native language is one other than English.
I am heavily invested in translating course content for GoBridge so we can offer them in other countries and maybe even for non-English speakers in the US.
If we go this route, it might be useful to have a feature switch so views for a specific language are only turned on once the translation for that language is completed.
The text was updated successfully, but these errors were encountered: