g11n

#52 Unable to push RHEL Japanese translations to upstream
Closed: Insufficient data by jibecfed. Opened by ljanda.

Closed: Insufficient data
Reopen Issue

During each RHEL release we are translating a bunch of most critical in-house and Fedora packages. The translation consists in translating untranslated strings and review of existing ones. Translation and review is done internally by a group of our internal translators.
It is unlikely our translators would be pushing those translations themselves to upstream and waiting for another review. The reason is that localization schedule is usually very tight, it happens at the very end of RHEL development schedule and we react at the most recent patches the packages have got.
As the RHEL l10n PgM I am worried about those Japanese translations which IMO would be beneficial for upstream. My other worry is also that it's difficult to keep them downstream because there is a risk of regressions and lost work of our internal translators.
I was recommended to reach out to each packager individually, and what's I am doing, but in some cases they really need clear instructions to follow. My personal recommendation would be each project in Zanata to have a RHEL7,RHEL8 etc branch where we would push our translations, and it would be up to community to decide whether they could leverage those or not...

Metadata Update from @ljanda:
- Issue private status set to: False (was: True)

Some notes form last meeting:

  • the work should be done upstream and not downstream, contacting package maintainer may help but won't change much for this matter
  • to make this works fine with the community, we need humans we can interact with (and to agree on common rules), using in-house translator is what Noriko suggested (I did the same, we do it in the French team too). We'll give them the appropriate rights to be able to push translation into the translation platform

In addition, branches creation should not be created only for translation purpose, because they will become out of sync really. Branches in software development are related to product life-cycle. If there isn't any support upstream for a package RHEL keep to a specific version, we can't do anything, because it means it isn't upstream. I would feel better to have branches that match maintained releases.

You may consider reversing your way of thinking, instead of paying for outsourcing companies to come translate for a specific RHEL version, you may pay them over time to maintain a good level of translation to upstream versions.

If your patches are bringing a few changes to strings, internal translator can fix it easily. If they do change a lot of things (which I doubt), it means you haven't upstreamed your changes, which can't be fix here.

Metadata Update from @jibecfed:
- Issue tagged with: l10n

I believe we can close this issue. Conclusions are clear from the above, I am not sure that pursuing this discussion would help to change them.

Metadata Update from @ljanda:
- Issue close_status updated to: Fixed
- Issue status updated to: Closed (was: Open)

Metadata Update from @jibecfed:
- Issue status updated to: Open (was: Closed)

We'll close this ticket in next meeting if needed. I'm sure the issue isn't solved already.

One example about what we should prevent: https://bugzilla.redhat.com/show_bug.cgi?id=1533495

I wonder how this could have happened as our team is translating RHEL to =
Japanese only=E2=80=A6=20

On 20 Feb 2018, at 22:56, Jean-Baptiste Holcroft pagure@pagure.io =
wrote:
=20
=20
jibecfed added a new comment to an issue you are following:
One example about what we should prevent: = https://bugzilla.redhat.com/show_bug.cgi?id=3D1533495
=20
To reply, visit the link below or just reply to this email
https://pagure.io/g11n/issue/52

Metadata Update from @jibecfed:
- Issue close_status updated to: Insufficient data
- Issue status updated to: Closed (was: Open)
Metadata
None

l10n

None
None
None
Static archive. pagure.io was sunset in 2026; this is a read-only snapshot.
Red Hat Logo

Fedora is sponsored by Red Hat. Learn more about the relationship between Red Hat and Fedora »

© Red Hat, Inc. and others.