Skip to content
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鈥檒l occasionally send you account related emails.

Already on GitHub? Sign in to your account

i18n: Harvesting client-side strings #6075

Closed
kevinkucharczyk opened this issue Nov 13, 2015 · 9 comments

Comments

@kevinkucharczyk
Copy link
Contributor

commented Nov 13, 2015

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

This comment has been minimized.

Copy link
Contributor

commented Nov 13, 2015

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

This comment has been minimized.

Copy link
Contributor Author

commented Nov 13, 2015

#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

This comment has been minimized.

Copy link
Contributor

commented Nov 13, 2015

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

This comment has been minimized.

Copy link
Contributor Author

commented Nov 13, 2015

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

This comment has been minimized.

Copy link

commented Dec 13, 2015

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

This comment has been minimized.

Copy link

commented Jan 27, 2016

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

@kevinkucharczyk

This comment has been minimized.

Copy link
Contributor Author

commented Jan 27, 2016

@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

This comment has been minimized.

Copy link

commented Jan 27, 2016

                                                                                  ember is not my pony 鈥巘o 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?  

鈥擱eply to this email directly or view it on GitHub.

@kevinansfield

This comment has been minimized.

Copy link
Contributor

commented Jan 18, 2017

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
4 participants
You can鈥檛 perform that action at this time.