How do we approach translation (i18n) of openshift

jwforres commented 9 years ago

See https://github.com/openshift/origin/pull/4332#issuecomment-155479889 for some background.

tagoh commented 9 years ago

Maybe good to follow up here.

1) This approach is using the strings themselves as the message ID for translation, what happens if you have the same word in english but intended for two different contexts that may need two different translations in certain languages? We should probably be using an actual identifier.

angular-gettext supports "contexts". see https://github.com/rubenv/angular-gettext/issues/223#issuecomment-145459238 for what I got from upstream when I have same question earlier. Honestly speaking, I don't mind either but IMO using an actual identifier like the way angular-translate and so on takes may introduces the poor outlook during the development cycle, particularly for an UI designer. or need extra toolset to replace translatable strings to identifiers, which needs an extra cost to do and has a risk not replaced as expected perhaps.

2) The web console is made up of UI bits coming from a number of shared UI repositories, each of which would have to be independently translated. We need to agree amongst the various projects contributing angular components what angular translation tool we are going to use. There are at least three other repos right now besides this one that would need translation.

How can we negotiate them for this? I've sent PR for some components already though.

3) We also have all of the templates the user can use to create content in their project. Those templates contain names and descriptions that the UI exposes to end users. https://github.com/openshift/openshift-ansible/tree/master/roles/openshift_examples/files/examples

We may need to take another approach for this indeed.

4) The API returns status messages, error messages, phases, and other various things that we show directly to end users.

Well, I'm not sure what is a concern though, frankly speaking there are no problem if targeted strings to be translated is in the translation database. just need to ensure if those are available in PO. it could be applied to the json things as well.

We need to have a larger discussion about the translation approach across the project stack, and need to approve a proposal before implementing something. ( https://github.com/openshift/origin/tree/master/docs/proposals ) Once we add the framework and the English translation we will have to maintain that for every new feature we add moving forward. It will add overhead to the project and slow it down. We need to make sure we are taking the correct approach before we agree to take on that overhead. @jwforres

Aha. Thank you for the explanation. apparently I'm not well understanding the process to propose something. I need to learn about it. I guess this issue is the place to discuss about the translation approach. so hope we have constructive discussion soon.

jwforres commented 9 years ago

cc'ing some folks @spadgett @liggitt @smarterclayton @bparees @stefwalter

stefwalter commented 9 years ago

The translation approach that I've seen openshift is in the right direction. My comments would be:

The source for translations needs to be pluggable. We have Cockpit loading po JSON files for a long time now (even though our i18n stuff isn't perfect), we probably want to keep the loading/delivery parts.
As @tagoh said contexts are the accepted solution for the same string meaning different things. We just have to get our contexts to line up between projects.
It needs to be dead easy for translation tools to scan for text to be translated, and it cannot be limited to a single set of tools. And this includes HTML attributes. That causes one of the problems that we see today in the Cockpit i18n infrastructure.
We need to come up with a standard place to push translations. We use Zanata right now.

CC @petervo

juhp commented 8 years ago

Should we create a document at https://github.com/openshift/origin/tree/master/docs/proposals to cover this proposal? Is there information about the process somewhere?

Is it possible to increase the priority for this? There is real demand for this for Japanese, Korean and Chinese users.

vanloswang commented 8 years ago

How about the progress now? Is there some design details for origin i18n?

jwforres commented 7 years ago

Some progress happening in upstream kubectl for the CLI https://github.com/kubernetes/kubernetes/pull/36802

stefwalter commented 7 years ago

For reference, in Cockpit we're using angular-gettext now for translating angular related code. We've found it easy to transform PO files to the angular-gettext require format, as well as share extraction tooling.

vanloswang commented 7 years ago

@jwforres The translation work done in Cockpit project is a good example. @stefwalter it seems like the k8s dashboard team has their's solution for i8n.

vanloswang commented 7 years ago

@jwforres @stefwalter @tagoh @juhp @bparees @danmcp Kubernetes dashboard has already released v1.6.1 with English, Janpanese and Chinese. Could we take the advantage of it?

xiaods commented 7 years ago

How about the progress now?

eliu commented 6 years ago

what is the progress now? no one follow up this issue?

openshift-bot commented 6 years ago

Issues go stale after 90d of inactivity.

Mark the issue as fresh by commenting /remove-lifecycle stale. Stale issues rot after an additional 30d of inactivity and eventually close. Exclude this issue from closing by commenting /lifecycle frozen.

If this issue is safe to close now please do so with /close.

/lifecycle stale

openshift-bot commented 6 years ago

Stale issues rot after 30d of inactivity.

Mark the issue as fresh by commenting /remove-lifecycle rotten. Rotten issues close after an additional 30d of inactivity. Exclude this issue from closing by commenting /lifecycle frozen.

If this issue is safe to close now please do so with /close.

/lifecycle rotten /remove-lifecycle stale

openshift-bot commented 6 years ago

Stale issues rot after 30d of inactivity.

Mark the issue as fresh by commenting /remove-lifecycle rotten. Rotten issues close after an additional 30d of inactivity. Exclude this issue from closing by commenting /lifecycle frozen.

If this issue is safe to close now please do so with /close.

/lifecycle rotten /remove-lifecycle stale

xiaods commented 6 years ago

OMG. /close it asap.

openshift-bot commented 6 years ago

Rotten issues close after 30d of inactivity.

Reopen the issue by commenting /reopen. Mark the issue as fresh by commenting /remove-lifecycle rotten. Exclude this issue from closing again by commenting /lifecycle frozen.

/close

openshift / origin

How do we approach translation (i18n) of openshift #5831