Re: [Openstack-i18n] .tx in git repository
Sorry for replying a bit late, I just recently joined the list. Meanwhile, .tx was removed from openstack-manuals. However, I think the points raised by Akihiro Motoki haven't been answered. Previously unaware of this discussion, I submitted https://review.openstack.org/#/c/81839/. In short, .tx/config should really be versioned since it contains repo-specific file-paths. While of course this can be autogenerated in the infra job, it doesn't help people that want to use local tools (such as vi / $FAVORITE_PO_EDITOR) instead of the Transifex web-interface. This also raises the side-question if it is acceptable to submit reviews that add translations or if those should somehow be imported into Transifex web instead and fetched via the infra job? -- Viele Grüße, Sascha Peilicke
On 03/21/2014 10:58 AM, Sascha Peilicke wrote:
Sorry for replying a bit late, I just recently joined the list. Meanwhile, .tx was removed from openstack-manuals. However, I think the points raised by Akihiro Motoki haven't been answered. Previously unaware of this discussion, I submitted https://review.openstack.org/#/c/81839/.
In short, .tx/config should really be versioned since it contains repo-specific file-paths. While of course this can be autogenerated in the infra job, it doesn't help people that want to use local tools (such as vi / $FAVORITE_PO_EDITOR) instead of the Transifex web-interface.
We faced a challenge with the infra job: The scripts currently assume that .tx/config does not change. But whenever we created a new file, it got updated and then the job failed since "git review" complained that the tree was not clean. So, if we add .tx/config again, we should update our scripts so that they handle creation of new manuals.
This also raises the side-question if it is acceptable to submit reviews that add translations or if those should somehow be imported into Transifex web instead and fetched via the infra job?
The infra job should do the job IMHO - but many of these are not properly setup or fail. For those failing, a review might be a quick first-aid. If you want to help fixing the broken post jobs, check on jenkins.openstack.org the translation jobs - and double check even the working ones, some fail silently ;( Andreas -- Andreas Jaeger aj@{suse.com,opensuse.org} Twitter/Identica: jaegerandi SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany GF: Jeff Hawn,Jennifer Guild,Felix Imendörffer,HRB16746 (AG Nürnberg) GPG fingerprint = 93A3 365E CE47 B889 DF7F FED1 389A 563C C272 A126
Hi, On Fri, Mar 21, 2014 at 7:12 PM, Andreas Jaeger <aj@suse.com> wrote:
On 03/21/2014 10:58 AM, Sascha Peilicke wrote:
Sorry for replying a bit late, I just recently joined the list. Meanwhile, .tx was removed from openstack-manuals. However, I think the points raised by Akihiro Motoki haven't been answered. Previously unaware of this discussion, I submitted https://review.openstack.org/#/c/81839/.
In short, .tx/config should really be versioned since it contains repo-specific file-paths. While of course this can be autogenerated in the infra job, it doesn't help people that want to use local tools (such as vi / $FAVORITE_PO_EDITOR) instead of the Transifex web-interface.
We faced a challenge with the infra job: The scripts currently assume that .tx/config does not change. But whenever we created a new file, it got updated and then the job failed since "git review" complained that the tree was not clean. So, if we add .tx/config again, we should update our scripts so that they handle creation of new manuals.
I think it is a balance between automated jobs on the infra side and conviniences for local translators. I don't have the right answer. I am working as upstream developer and local translator, so I understand the both situation but I am afraid we lose local volunteers by increasing hurdles to local volunteers. # From my experience, removing .tx/config discouraged me to setup translation # check site. Ah, I need to prepare .tx/config again.... let's do it later, next week? next month? # Japanese translation site might break due to removing .tx/config but I am not sure # and cannot take care of it soon. .tx/config is required to generate translated manuals to check their translations. Ideally such features will be covered by infra, but it needs more efforts by doc and I18N team and it is not ready now. Personally I just forked OpenStack manuals to keep .tx/config to make sure my translation check site work (which is synced with the upstream by cron) to reduce my efforts. This is the real. # I am also planing to share .tx/config in https://github.com/OpenStack-I18N # but I don't have no good idea how to share :-(
This also raises the side-question if it is acceptable to submit reviews that add translations or if those should somehow be imported into Transifex web instead and fetched via the infra job?
The infra job should do the job IMHO - but many of these are not properly setup or fail. For those failing, a review might be a quick first-aid. If you want to help fixing the broken post jobs, check on jenkins.openstack.org the translation jobs - and double check even the working ones, some fail silently ;(
I agree importing translations by infra jobs. However there are many things to be considered: * when we should switch the target branch of translations (master vs milestone-proposed vs stable/***) (milestone-proposed branch is the most tricky thing) * how we can handle stable branches (all people do not want to work on master branch) This is the reason that Horizon translation import is now done manually. Importing translations automatically doesn't necessarilly work for all cases. Andreas made great jobs on documentation and infra setup. I would like to make OpenStack infra better as a whole too. My post is just intended to share my general concern how to feel more light contributors comfortable. I hope it never discourages you all :) Thanks, Akihiro
Andreas -- Andreas Jaeger aj@{suse.com,opensuse.org} Twitter/Identica: jaegerandi SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany GF: Jeff Hawn,Jennifer Guild,Felix Imendörffer,HRB16746 (AG Nürnberg) GPG fingerprint = 93A3 365E CE47 B889 DF7F FED1 389A 563C C272 A126
_______________________________________________ Openstack-i18n mailing list Openstack-i18n@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-i18n
On 03/21/2014 05:35 PM, Akihiro Motoki wrote:
Hi,
On Fri, Mar 21, 2014 at 7:12 PM, Andreas Jaeger <aj@suse.com> wrote:
On 03/21/2014 10:58 AM, Sascha Peilicke wrote:
Sorry for replying a bit late, I just recently joined the list. Meanwhile, .tx was removed from openstack-manuals. However, I think the points raised by Akihiro Motoki haven't been answered. Previously unaware of this discussion, I submitted https://review.openstack.org/#/c/81839/.
In short, .tx/config should really be versioned since it contains repo-specific file-paths. While of course this can be autogenerated in the infra job, it doesn't help people that want to use local tools (such as vi / $FAVORITE_PO_EDITOR) instead of the Transifex web-interface.
We faced a challenge with the infra job: The scripts currently assume that .tx/config does not change. But whenever we created a new file, it got updated and then the job failed since "git review" complained that the tree was not clean. So, if we add .tx/config again, we should update our scripts so that they handle creation of new manuals.
I think it is a balance between automated jobs on the infra side and conviniences for local translators. I don't have the right answer. I am working as upstream developer and local translator, so I understand the both situation but I am afraid we lose local volunteers by increasing hurdles to local volunteers.
Since this thread has started, I've hardened our infra scripts so that they can work with and without a .tx/config file. I understand the situation better now and I'm fine with adding it back - and would then also add some logic to handle the problems we faced better.
# From my experience, removing .tx/config discouraged me to setup translation # check site. Ah, I need to prepare .tx/config again.... let's do it later, next week? next month? # Japanese translation site might break due to removing .tx/config but I am not sure # and cannot take care of it soon.
.tx/config is required to generate translated manuals to check their translations. Ideally such features will be covered by infra, but it needs more efforts by doc and I18N team and it is not ready now.
Personally I just forked OpenStack manuals to keep .tx/config to make sure my translation check site work (which is synced with the upstream by cron) to reduce my efforts. This is the real. # I am also planing to share .tx/config in https://github.com/OpenStack-I18N # but I don't have no good idea how to share :-(
This also raises the side-question if it is acceptable to submit reviews that add translations or if those should somehow be imported into Transifex web instead and fetched via the infra job?
The infra job should do the job IMHO - but many of these are not properly setup or fail. For those failing, a review might be a quick first-aid. If you want to help fixing the broken post jobs, check on jenkins.openstack.org the translation jobs - and double check even the working ones, some fail silently ;(
I agree importing translations by infra jobs.
However there are many things to be considered: * when we should switch the target branch of translations (master vs milestone-proposed vs stable/***) (milestone-proposed branch is the most tricky thing) * how we can handle stable branches (all people do not want to work on master branch) This is the reason that Horizon translation import is now done manually. Importing translations automatically doesn't necessarilly work for all cases.
Argh ;( I just proposed a patch to do this: https://review.openstack.org/#/c/82176/ So, should I remove that again? I do think doing it for master is fine - and if you want to import other branches, do it locally. But you've more experience here than me as newcomer...
Andreas made great jobs on documentation and infra setup. I would like to make OpenStack infra better as a whole too. My post is just intended to share my general concern how to feel more light contributors comfortable. I hope it never discourages you all :)
It just shows it's more complex than native AJ expected ;) Andreas -- Andreas Jaeger aj@{suse.com,opensuse.org} Twitter/Identica: jaegerandi SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany GF: Jeff Hawn,Jennifer Guild,Felix Imendörffer,HRB16746 (AG Nürnberg) GPG fingerprint = 93A3 365E CE47 B889 DF7F FED1 389A 563C C272 A126
On 03/21/2014 08:42 PM, Andreas Jaeger wrote:
On 03/21/2014 05:35 PM, Akihiro Motoki wrote:
Hi,
On Fri, Mar 21, 2014 at 7:12 PM, Andreas Jaeger <aj@suse.com> wrote:
On 03/21/2014 10:58 AM, Sascha Peilicke wrote:
Sorry for replying a bit late, I just recently joined the list. Meanwhile, .tx was removed from openstack-manuals. However, I think the points raised by Akihiro Motoki haven't been answered. Previously unaware of this discussion, I submitted https://review.openstack.org/#/c/81839/.
In short, .tx/config should really be versioned since it contains repo-specific file-paths. While of course this can be autogenerated in the infra job, it doesn't help people that want to use local tools (such as vi / $FAVORITE_PO_EDITOR) instead of the Transifex web-interface.
We faced a challenge with the infra job: The scripts currently assume that .tx/config does not change. But whenever we created a new file, it got updated and then the job failed since "git review" complained that the tree was not clean. So, if we add .tx/config again, we should update our scripts so that they handle creation of new manuals.
I think it is a balance between automated jobs on the infra side and conviniences for local translators. I don't have the right answer. I am working as upstream developer and local translator, so I understand the both situation but I am afraid we lose local volunteers by increasing hurdles to local volunteers.
Since this thread has started, I've hardened our infra scripts so that they can work with and without a .tx/config file.
I understand the situation better now and I'm fine with adding it back - and would then also add some logic to handle the problems we faced better.
I've send now this patch: https://review.openstack.org/#/c/82384/ It takes care that the propose job will succeed if .tx/config gets updated. With that change in, we can add .tx/config to any project as convenient. So, now I'm in fine with adding .tx/init back in. Daisy, are you happy as well? Andreas -- Andreas Jaeger aj@{suse.com,opensuse.org} Twitter/Identica: jaegerandi SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany GF: Jeff Hawn,Jennifer Guild,Felix Imendörffer,HRB16746 (AG Nürnberg) GPG fingerprint = 93A3 365E CE47 B889 DF7F FED1 389A 563C C272 A126
Looks nice to me. Thanks, Akihiro On Mon, Mar 24, 2014 at 5:44 AM, Andreas Jaeger <aj@suse.com> wrote:
On 03/21/2014 08:42 PM, Andreas Jaeger wrote:
On 03/21/2014 05:35 PM, Akihiro Motoki wrote:
Hi,
On Fri, Mar 21, 2014 at 7:12 PM, Andreas Jaeger <aj@suse.com> wrote:
On 03/21/2014 10:58 AM, Sascha Peilicke wrote:
Sorry for replying a bit late, I just recently joined the list. Meanwhile, .tx was removed from openstack-manuals. However, I think the points raised by Akihiro Motoki haven't been answered. Previously unaware of this discussion, I submitted https://review.openstack.org/#/c/81839/.
In short, .tx/config should really be versioned since it contains repo-specific file-paths. While of course this can be autogenerated in the infra job, it doesn't help people that want to use local tools (such as vi / $FAVORITE_PO_EDITOR) instead of the Transifex web-interface.
We faced a challenge with the infra job: The scripts currently assume that .tx/config does not change. But whenever we created a new file, it got updated and then the job failed since "git review" complained that the tree was not clean. So, if we add .tx/config again, we should update our scripts so that they handle creation of new manuals.
I think it is a balance between automated jobs on the infra side and conviniences for local translators. I don't have the right answer. I am working as upstream developer and local translator, so I understand the both situation but I am afraid we lose local volunteers by increasing hurdles to local volunteers.
Since this thread has started, I've hardened our infra scripts so that they can work with and without a .tx/config file.
I understand the situation better now and I'm fine with adding it back - and would then also add some logic to handle the problems we faced better.
I've send now this patch: https://review.openstack.org/#/c/82384/
It takes care that the propose job will succeed if .tx/config gets updated. With that change in, we can add .tx/config to any project as convenient.
So, now I'm in fine with adding .tx/init back in.
Daisy, are you happy as well?
Andreas -- Andreas Jaeger aj@{suse.com,opensuse.org} Twitter/Identica: jaegerandi SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany GF: Jeff Hawn,Jennifer Guild,Felix Imendörffer,HRB16746 (AG Nürnberg) GPG fingerprint = 93A3 365E CE47 B889 DF7F FED1 389A 563C C272 A126
participants (3)
-
Akihiro Motoki
-
Andreas Jaeger
-
Sascha Peilicke