i18n: Harvesting client-side strings

[kevinkucharczyk]

This is part of the i18n project described in #5345. I'd love to see some progress on this 😄

Harvesting server side strings is already in progress (see issue #5617), but we also need to start isolating strings inside the Ember app. This should be done using the ember-intl addon.

This is a big job, as we have lots of templates and .js files that have English strings which need to be moved to a translations file and hooked up with ember-intl.

So, the first thing to do is to setup the Ghost Ember app to work with ember-intl. I believe we should use the 2.0 branch of the project (as @morficus showed in his proof of concept). Once this is done, we can start working on translating individual files.

I've checked which files contain strings needing translating and this is what I found:

• /core/client/app/assets/lib/uploader.js
• /core/client/app/components
  • gh-search-input.js
  • gh-upload-modal.js
  • gh-user-invited.js
• /core/client/app/controllers/modals (multiple files)
• /core/client/app/controllers/settings/labs.js
• /core/client/app/controllers/setup (multiple files)
• /core/client/app/controllers/team/user.js
• /core/client/app/controllers/error.js
• /core/client/app/controllers/post-settings-menu.js
• /core/client/app/controllers/signin.js
• /core/client/app/controllers/signup.js
• /core/client/app/html (multiple files)
• /core/client/app/mixins
  • editor-base-controller.js
  • pagination-route.js
• /core/client/app/models/user.js
• /core/client/app/routes (most routes have a titleToken that should be translated + some have alerts/other strings)
• /core/client/app/services/notifications.js
• /core/client/app/templates (pretty much all template files have English strings that need to be isolated)
• /core/client/app/utils
  • ajax.js
  • titleize.js (how would we handle this util in regards to i18n?)
• /core/client/app/validators (multiple files)

As you can see, there's a lot to do here. If you're willing to work on this, feel free to leave a comment stating the files you're translating.

If there's anything I missed - please let me know!

To the Ghost Core team - if this is not the right time for translating client-side strings, then we could close this issue for now and open it up again later.

[kevinansfield]

Thanks @kevinkucharczyk! I'm definitely up for starting work on this sooner rather than later as we're only going to gather more strings to translate as time goes by.

As you say the first step is to get ember-intl set up - this is something I'd like to do once #5970, #6020 and a forthcoming ember-cli upgrade are merged and confirmed working. There is also on-going work on the client-side acceptance tests (#6039) which I'd like to get in place before we start moving too far with i18n as they should provide more confidence that we're not breaking anything as we go.

Once ember-intl has been properly set up I'm fine with pulling out strings and switching to i18n helpers incrementally. I think we'll also want to come up with a method of testing our internationalisation - if you or anyone has any experience or ideas surrounding that I'd definitely be interested in hearing them.

Finally, in order to add full internationalisation on the client we also need to consider #6050 and how we want to handle translation of API-provided messages.

In conclusion, there's a lot to be done but nothing which can't be done incrementally, especially if it's taken into consideration when other changes are made.

[kevinkucharczyk]

#6050 is an interesting one. I kinda like the idea of providing an i18n key to the client, which would look up its own translations.

However, we are also translating the API messages themselves (in #5617), so I'm worried that this might lead to duplicate strings - they'd exist in both the client and server translation jsons and we would always need to be sure to update both files whenever we change one of the strings.

[kevinansfield]

Yeah, it's an interesting one - my initial thoughts on #6050 were that the API should be language-agnostic otherwise for every API request we also have to pass which language we expect back. However, if that is the case we would then expect any other clients of the API to use the default english response, provide their own translations, or offer some way for clients to retrieve language packs from the API that they could use for local translations.

[kevinkucharczyk]

We could add an Accept-Language header to all requests by modifying the Adapter in Ember. The server could use that to determine which translation it should send back and fall back to english if no header is provided.

[matitalatina]

I started this job.
This is my first contribution so fell free to warn me if I'm doing it wrong ;).
https://github.com/matitalatina/Ghost/tree/i18n-client

[qLb]

i'd be glad to help on that, just point me in the right direction @kevinkucharczyk

[kevinkucharczyk]

@qLb I think we're still waiting for the acceptance tests (#6039) to be finished before moving on with the harvesting. Perhaps you could help out with the tests? 😃

[qLb]

                                                                                  ember is not my pony ‎to be honest but sure, i'll do my best to push it further :) pzdr                                                                                                                                                                                                                                                                                                                                        qL.b                                                                                                                                                                                                                From: Kevin P. KucharczykSent: środa, 27 stycznia 2016 18:56To: TryGhost/GhostReply To: TryGhost/GhostCc: qLbSubject: Re: [Ghost] i18n: Harvesting client-side strings (#6075)@qLb I think we're still waiting for the acceptance tests (#6039) to be finished before moving on with the harvesting. Perhaps you could help out with the tests?  

—Reply to this email directly or view it on GitHub.

[kevinansfield]

The list of files requiring translation is out of date and the proposed addon for handling i18n also needs review - it looks like ember-i18n is now preferred option.

I'm going to close for now and mark as later to clean up and focus our issue list.