Re: [openstack-dev] OpenStack Meiji (明治) - Our next release name has been selected

[Ian Y. Choi]

Hello,

I think the third name 'Meiji' may arise some historical and political
debates in East Asia, as far as I know.

Could you share what significant identified problems are on the first two
selected from our election?


With many thanks,

/Ian

On Tue, Jul 7, 2015 at 8:55 PM, Masayuki Igawa 
wrote:

> Hi,
> # I'm a native Japanese speaker :-)
>
> 2015年7月7日(火) 20:33 Amrith Kumar :
>
>> Maybe this (the google answer)?
>>
>> www.youtube.com/watch?v=Qvw0A12aOGQ
>
>
> Yeah, this is correct pronunciation.
>
>
>> But someone who is a native Japanese speaker should confirm.
>>
>
> https://www.youtube.com/watch?v=D9vwge557hY
> I think this is a casual version and Japanese people are familiar with
> this.
>
> Thanks,
> -- Masayuki Igawa
>
>
>> -amrith
>>
>> P.S. the yahoo answer suggests that you pronounce it as "Meh - gee" with
>> the emphasis on the "meh" ;)
>>
>> -Original Message-
>> From: Matthias Runge [mailto:mru...@redhat.com]
>> Sent: Tuesday, July 07, 2015 6:08 AM
>> To: openstack-dev@lists.openstack.org
>> Subject: Re: [openstack-dev] OpenStack Meiji (明治) - Our next release name
>> has been selected
>>
>> On Mon, Jul 06, 2015 at 11:48:13PM -0400, Monty Taylor wrote:
>> > significant identified problems... but the third in the list, Meiji (明
>> > 治) is clear.
>> >
>> > So please join me in welcoming the latest name to our family ... and
>> > if you, like me, are not a native Japanese speaker, in learning two
>> > new characters.
>>
>> Could someone provide a hint please, how to pronounce this properly?
>> --
>> Matthias Runge 
>>
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe:
>> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe:
>> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
> --
> -- Masayuki Igawa
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] OpenStack Meiji (明治) - Our next release name has been selected

[Ian Y. Choi]

Hello Monty,

Has the third candidate for our next release name 'Meiji' been 
determined and finalized?


I know we are following open and relevant procedures (e.g., public 
polls) to determine our next release name, but
I am asking it because I think 'Meiji' as our next release name would 
become a serious hot potato, as Clint shared one URL.


(Clint, Thank you for finding some materials related to this issue.)


With many thanks,

/Ian

Clint Byrum wrote on 7/8/2015 2:18 AM:

http://afe.easia.columbia.edu/main_pop/kpct/kp_meiji.htm

There's a summary of what Meiji might mean to historians. I'm not sure if
OpenStack needs to be too concerned about this, but I believe this is what
Ian is referring to as "historical and political debates in East Asia."

Seems like a hot-button name for OpenStack to adopt.

Excerpts from Ian Y. Choi's message of 2015-07-07 05:40:52 -0700:

Hello,

I think the third name 'Meiji' may arise some historical and political
debates in East Asia, as far as I know.

Could you share what significant identified problems are on the first two
selected from our election?


With many thanks,

/Ian

On Tue, Jul 7, 2015 at 8:55 PM, Masayuki Igawa 
wrote:


Hi,
# I'm a native Japanese speaker :-)

2015年7月7日(火) 20:33 Amrith Kumar :


Maybe this (the google answer)?

www.youtube.com/watch?v=Qvw0A12aOGQ


Yeah, this is correct pronunciation.



But someone who is a native Japanese speaker should confirm.


https://www.youtube.com/watch?v=D9vwge557hY
I think this is a casual version and Japanese people are familiar with
this.

Thanks,
-- Masayuki Igawa



-amrith

P.S. the yahoo answer suggests that you pronounce it as "Meh - gee" with
the emphasis on the "meh" ;)

-Original Message-
From: Matthias Runge [mailto:mru...@redhat.com]
Sent: Tuesday, July 07, 2015 6:08 AM
To: openstack-dev@lists.openstack.org
Subject: Re: [openstack-dev] OpenStack Meiji (明治) - Our next release name
has been selected

On Mon, Jul 06, 2015 at 11:48:13PM -0400, Monty Taylor wrote:

significant identified problems... but the third in the list, Meiji (明
治) is clear.

So please join me in welcoming the latest name to our family ... and
if you, like me, are not a native Japanese speaker, in learning two
new characters.

Could someone provide a hint please, how to pronounce this properly?
--
Matthias Runge 

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe:
openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe:
openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


--
-- Masayuki Igawa

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev



__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev



__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [I18n] Pike PTG Summary

[Ian Y. Choi]

Hello all,


I18n team participated in PTG for horizontal discussions with the tight
collaboration of Documentation team on Monday and Tuesday.

Also, there were a few collaboration sessions with Infrastructure, Horizon,
Release Management, and OpenStackAnsible team on Wednesday & Thursday in a
reservable room.


The following is the summary of what I18n team discussed with other project
teams.

More details for I18n issues are available at:
https://etherpad.openstack.org/p/i18n-ptg-pike-topics



1. Documentation / I18n (Monday & Tuesday)


The details of all discussions with Docs & I18n teams are written in:
https://etherpad.openstack.org/p/docs-i18n-ptg-pike ,

and I would like to summarize mainly I18n issues (For Documentation topic
summary, please see [1]).


- For Horizon strings, Documentation team & I18n team identified

 : Documentation team wants to implement automated screenshot functionality
for user-guide. Then, stable DevStack

   instance would be fine with adding the functionality.

 : On the other hand, I18n team wants to implement translation checksite
which requires re-import of translated strings

   to review translated strings after around Soft & Hard StringFreezes.


- Agreed that archiving & versioning [2] translated documents are also the
target with consideration.


- Defined url policy for translated project specific install guides

 : https://docs.openstack.org (e.g.,
https://docs.openstack.org/project-install-guide/baremetal/ja/newton/ )


- I18n team will implement to generate translated PDF documents after pdf
implementation spec [3] is successfully landed.


- I18n team discussed the approach for implementing translation checksite,
I18n contributor guide translation,

  considering different release models, and solving Stackalytics
integration issues.



2. Infrastructure + I18n (Wednesday) + OpenStackAnsible + Horizon (Thursday)


- Translation platform ( https://translate.openstack.org ) is now ready for
upgrade.


- There will be upgrade during 2/27 - 3/3. Translation platform might not
work due to upgrade progress.


- openstackid-dev developer will test authentication with Zanata using
https://translate-dev.o.o from next week


- I18n team will automate to propose ATC status rather than current manual
proposal work as extra-ATCs using upgraded translation platform.


- Implementing translation checksite with OpenStackAnsible will be a
feasible solution in OpenStack Infrastructure. I18n team will start to
implement translation checksite using OpenStackAnsible from Pike cycle
(spec [4] needs to be changed).


- Discussed how to Improve algorithms to match Zanata ID with Launchpad &
Gerrit ID in Stackalytics



3. Horizon I18n collaboration session w/ Release Management team


- Shared current status of I18n team’s translation priority

  : I18n team sets the highest priority during Soft & Hard StringFreezes to
include more qualified translated strings

  as much as possible for Horizon & Horizon plugin projects.


- I18n team shared Ocata cycle experience: cycle-with-milestone,
cycle-with-intermediary, and cycle-trailing release models

  for Horizon plugin projects are not matched with Soft & Hard StringFreeze
periods.


- Discussed & drawn a new proposal to consider translations for Horizon
plugin projects

 : I18n team will consider Soft & Hard StringFreeze for the projects which
follow cycle-with-milestone release model.

 : I18n team will also consider translation with releases for the projects
which follow cycle-with-intermediary release model if they are fine
following deadlines.

 : I18n team will propose a specification to tag (e.g., with “translate”)
for projects which are the target of translations with managing

   stable branches in translation platform.

 : For cycle-trailing release models, I18n will consider translations with
managing stable versions in translation platform

if there is I18n cross-project liaison [5] for the project.

 : I18n team will higher priority for projects which have I18n
cross-project liaison.


- I18n team will ask to Zanata development team to automate to create new
stable versions in Zanata, copying master translations over.



I great appreciate all the help and support from especially Alex - Pike
Docs PTL to help successfully land collaboration room with I18n team, and
also many project team contributors to participate in the discussion and
draw nice, and cool approach for better internationalization.



With many thanks,


/Ian


[1]
http://lists.openstack.org/pipermail/openstack-dev/2017-February/112885.html

[2]
http://specs.openstack.org/openstack/docs-specs/specs/pike/archiving.html

[3]
http://specs.openstack.org/openstack/docs-specs/specs/ocata/build-pdf-from-rst-guides.html

[4]
http://specs.openstack.org/openstack-infra/infra-specs/specs/translation_check_site.html

[5] https://wiki.openstack.org/wiki/CrossProjectLiaisons#I18n
__
OpenStac

[openstack-dev] [I18n] Translation platform may be unstable or down during 2/27 - 3/3 due to upgrade

[Ian Y. Choi]

Hello all,


As I shared I18n summary in my previous e-mail [1],

there will be a major OpenStack translation platform upgrade during Feb 27
to Mar 3.


It implies that:


- Translation platform (https://translate.openstack.org) might be unstable
or might

  not work for some time slots during the upgrade period.


- “Imported Translation from Zanata” patch proposals [2] might not work.


- Translation sync jobs [3, 4] may fail during some period.


Infrastructure team kindly agreed to help a lot for the translation
platform upgrade (I truly appreciate it!), and I18n team & Zanata [5]
development team will have high attention on upgrade and changes.


Note that the current Zanata version is 3.7.3, and the target upgrade
version is 3.9.6.



With many thanks,


/Ian


[1]
http://lists.openstack.org/pipermail/openstack-dev/2017-February/112889.html

[2]
https://review.openstack.org/#/q/owner:%22OpenStack+Proposal+Bot%22+%22Imported+Translations+from+Zanata%22

[3]
http://status.openstack.org/openstack-health/#/g/build_queue/post?groupKey=build_queue&searchJob=translation

[4]
http://status.openstack.org/openstack-health/#/g/build_queue/periodic?groupKey=build_queue&searchJob=translation

[5] http://zanata.org
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [i18n] [nova] understanding log domain change - https://review.openstack.org/#/c/439500

[Ian Y. Choi]

Doug Hellmann wrote on 3/7/2017 12:53 AM:

Excerpts from Sean Dague's message of 2017-03-06 09:06:18 -0500:

On 03/06/2017 08:43 AM, Andreas Jaeger wrote:

On 2017-03-06 14:03, Sean Dague  wrote:

I'm trying to understand the implications of
https://review.openstack.org/#/c/439500. And the comment in the linked
email:

">> Yes, we decided some time ago to not translate the log files anymore and

thus our tools do not handle them anymore - and in general, we remove
these kind of files."

Does that mean that all the _LE, _LI, _LW stuff in projects should be
fully removed? Nova currently enforces those things are there -
https://github.com/openstack/nova/blob/e88dd0034b1b135d680dae3494597e295add9cfe/nova/hacking/checks.py#L314-L333
and want to make sure our tools aren't making us do work that the i18n
team is ignoring and throwing away.

Sean, this was removed as followup to:

http://lists.openstack.org/pipermail/openstack-i18n/2016-November/002574.html

Let me copy Ian as i18n PTL,

Andreas

That all seems reasonable, and I'm happy to follow the i18n team's lead
here. It is however a significant reversal of policy, and there is
substantial code infrastructure in projects (like Nova) to support the
old policy.

So if this is new policy, a much wider dissemination of it would be
welcomed, as it means we can purge this infrastructure from projects
like Nova.

 -Sean


Yes, we went to a great deal of trouble to enable log translations,
so I'm surprised to see it being dropped to quickly.  I don't
necessarily disagree with the decision, because I know translator
time is limited. But it would be nice to have the discussion here,


+1 and for such discussions including openstack-i...@lists.openstack.org 
mailing list would be also nice :)


On Barcelona Design Summit, there were I18n contributor meetup and I18n 
team members discussed a lot.

One of things was not to translate log-level strings for server projects.

Note that such decision was made not because translator time is limited.

Log messages are important to better identify which errors are being 
posed and most operators (+ developers)

diagnose and start to solve error situations from the log messages.
I18n team previously translated log messages a lot especially thanks to 
translation contribution from IBM. (AFAIK)
However, after then, there have been some voices - why I18n team 
translated log messages?
After listening to the voices in details, I18n team identified that the 
background of such voices was related with searching log messages on 
Internet.
Searching English log messages on the Internet will retrieve more number 
of results than searching translated log messages on the Internet.


Translating log messages now has two different point of views:
 - Will be useful for OpenStack users to better understand log messages 
in details with translated log messages?
 - Or will not be useful for OpenStack users because the original log 
messages will have better chance to find solutions who occurred the 
similar cases on the Internet?


I18n team discussed with such point of views and on Barcelona Summit the 
latter point would be more important than the former point.
Also, it would be just a point of view from PTL, but it is difficult for 
me to encourage to contribution translations which have such kind of 
controversy.


Now I would like to listen again to not only developers, but also 
operators and translators - for log string translation.
If someone thinks that the former point would be more important than the 
latter point, please share through this mailing list to reconsider the 
current decision.



With many thanks,

/Ian


instead of on a list most of the community isn't subscribed to, so
everyone involved can understand the reason for the change and so
the folks who asked for it originally can be included in the
conversation. As Sean points out, the policy change has a lot of
other implications about how logging is handled throughout the
applications.

Doug

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev




__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [i18n] [nova] understanding log domain change - https://review.openstack.org/#/c/439500

[Ian Y. Choi]

Doug Hellmann wrote on 3/9/2017 9:24 PM:

Excerpts from Sean McGinnis's message of 2017-03-07 07:17:09 -0600:

On Mon, Mar 06, 2017 at 09:06:18AM -0500, Sean Dague wrote:

On 03/06/2017 08:43 AM, Andreas Jaeger wrote:

On 2017-03-06 14:03, Sean Dague  wrote:

I'm trying to understand the implications of
https://review.openstack.org/#/c/439500. And the comment in the linked
email:

">> Yes, we decided some time ago to not translate the log files anymore and

thus our tools do not handle them anymore - and in general, we remove
these kind of files."

Does that mean that all the _LE, _LI, _LW stuff in projects should be
fully removed? Nova currently enforces those things are there -
https://github.com/openstack/nova/blob/e88dd0034b1b135d680dae3494597e295add9cfe/nova/hacking/checks.py#L314-L333
and want to make sure our tools aren't making us do work that the i18n
team is ignoring and throwing away.

So... just looking for a definitive statement on this since there has
been some back and forth discussion.

Is it correct to say - all projects may (should?) now remove all bits in
place for using and enforcing the _Lx() translation markers. Only _()
should be used for user visible error messages.

Sean (smcginnis)


The situation is still not quite clear to me, and it would be
unfortunate to undo too much of the translation support work because
it will be hard to redo it.

Is there documentation somewhere describing what the i18n team has
committed to trying to translate?


I18n team describes translation plan and priority in Zanata - 
translation platform

 : https://translate.openstack.org/ .


  I think I heard that there was a
shift in emphasis to "user interfaces", but I'm not sure if that
includes error messages in services. Should we remove all use of
oslo.i18n from services? Or only when dealing with logs?


When I18n team decided to removal of log translations in Barcelona last 
October, there had been no

discussion on the removal of oslo.i18n translation support for log messages.
(I have kept track of what I18n team discussed during Barcelona I18n 
meetup on Etherpad - [1])


Now I think that the final decision of oslo.i18n log translation support 
needs more involvement
with translators considering oslo.i18n translation support, and also 
more people on community wide including

project working groups, user committee, and operators as Matt suggested.

If translating log messages is meaningful to some community members and 
some translators show interests
on translating log messages, then I18n team can revert the policy with 
rolling back of translations.
Translated strings are still alive in not only previous stable branches, 
but also in translation memory in Zanata - translation platform.


I would like to find some ways to discuss this topic with more community 
wide.



With many thanks,

/Ian

[1] https://etherpad.openstack.org/p/barcelona-i18n-meetup



Doug

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev




__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] A Summary of Atlanta PTG Summaries (!)

[Ian Y. Choi]

Hello Hugh,

Just I have found that there is a typo: I18n team is "I18n", not "I8n" :)
(There are total 18 characters between 'I' and 'n' in 
"Internationalization" - too long.)

Could you fix it?


With many thanks,

/Ian

Hugh Blemings wrote on 3/13/2017 6:30 PM:

Hi Emilien, All,

On 8/3/17 09:26, Emilien Macchi wrote:
On Mon, Mar 6, 2017 at 10:45 PM, Hugh Blemings  
wrote:

Hiya,

As has been done for the last few Summits/PTGs in Lwood[1] I've pulled
together a list of the various posts to openstack-dev that summarise 
things

at the PTG - projects, videos, anecdotes etc.

The aggregated list is in this blog post;

http://hugh.blemings.id.au/2017/03/07/openstack-ptg-atlanta-2017-summary-of-summaries/ 



Which should aggregate across to planet.openstack.org as well.

I'll update this as further summaries appear, corrections/contributions
welcome.


Thanks Hugh, that's awesome!


Most welcome :)


Can you please remove the first link: TripleO:
http://lists.openstack.org/pipermail/openstack-dev/2017-February/112893.html 


and only keep this one:
http://lists.openstack.org/pipermail/openstack-dev/2017-February/112995.html 



Done, apologies for the delay, got behind in my email this week!

Cheers,
Hugh


__ 


OpenStack Development Mailing List (not for usage questions)
Unsubscribe: 
openstack-dev-requ...@lists.openstack.org?subject:unsubscribe

http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev




__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [i18n] [nova] understanding log domain change - https://review.openstack.org/#/c/439500

[Ian Y. Choi]

Doug Hellmann wrote on 3/10/2017 11:39 PM:

Excerpts from Doug Hellmann's message of 2017-03-10 09:28:52 -0500:

Excerpts from Ian Y. Choi's message of 2017-03-10 01:22:40 +0900:

Doug Hellmann wrote on 3/9/2017 9:24 PM:

Excerpts from Sean McGinnis's message of 2017-03-07 07:17:09 -0600:

On Mon, Mar 06, 2017 at 09:06:18AM -0500, Sean Dague wrote:

On 03/06/2017 08:43 AM, Andreas Jaeger wrote:

On 2017-03-06 14:03, Sean Dague  wrote:

I'm trying to understand the implications of
https://review.openstack.org/#/c/439500. And the comment in the linked
email:

">> Yes, we decided some time ago to not translate the log files anymore and

thus our tools do not handle them anymore - and in general, we remove
these kind of files."

Does that mean that all the _LE, _LI, _LW stuff in projects should be
fully removed? Nova currently enforces those things are there -
https://github.com/openstack/nova/blob/e88dd0034b1b135d680dae3494597e295add9cfe/nova/hacking/checks.py#L314-L333
and want to make sure our tools aren't making us do work that the i18n
team is ignoring and throwing away.

So... just looking for a definitive statement on this since there has
been some back and forth discussion.

Is it correct to say - all projects may (should?) now remove all bits in
place for using and enforcing the _Lx() translation markers. Only _()
should be used for user visible error messages.

Sean (smcginnis)


The situation is still not quite clear to me, and it would be
unfortunate to undo too much of the translation support work because
it will be hard to redo it.

Is there documentation somewhere describing what the i18n team has
committed to trying to translate?

I18n team describes translation plan and priority in Zanata -
translation platform
   : https://translate.openstack.org/ .


   I think I heard that there was a
shift in emphasis to "user interfaces", but I'm not sure if that
includes error messages in services. Should we remove all use of
oslo.i18n from services? Or only when dealing with logs?

When I18n team decided to removal of log translations in Barcelona last
October, there had been no
discussion on the removal of oslo.i18n translation support for log messages.
(I have kept track of what I18n team discussed during Barcelona I18n
meetup on Etherpad - [1])

Now I think that the final decision of oslo.i18n log translation support
needs more involvement
with translators considering oslo.i18n translation support, and also
more people on community wide including
project working groups, user committee, and operators as Matt suggested.

If translating log messages is meaningful to some community members and
some translators show interests
on translating log messages, then I18n team can revert the policy with
rolling back of translations.
Translated strings are still alive in not only previous stable branches,
but also in translation memory in Zanata - translation platform.

I would like to find some ways to discuss this topic with more community
wide.

I would suggest that we discuss this at the Forum in Boston, but I think
we need to gather some input before then because if there is a consensus
that log translations are not useful we can allow the code cleanup to
occur and not take up face-to-face time.

I've started a thread on the operators mailing list [1].


Thanks a lot, Doug!

I do not know how to reply to [1] as an un-subscriber of 
openstack-operator mailing list using my Mail client program,
but since there is no response from APAC for several days [2], I asked 
Japanese & Chinese language coordinators and community leader /

ambassador to collect and tell opinions on [2].

I am now receiving opinions from Korean users & operators and currently 
there are about 10 comments all mentioning

that log translation functionality is not needed.

I will keep update if I receive more opinion on this issue.


With many thanks,

/Ian

[2] 
http://lists.openstack.org/pipermail/openstack-operators/2017-March/012902.html



Doug

[1] 
http://lists.openstack.org/pipermail/openstack-operators/2017-March/012887.html

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev




__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [ptls] Project On-Boarding Rooms

[Ian Y. Choi]

Hello Kendall!

I18n team loves to have a project on-boarding room for new translators :)
Please reserve a room for I18n if available.


With many thanks,

/Ian


Kendall Nelson wrote on 3/16/2017 3:20 AM:

Hello All!

As you may have seen in a previous thread [1] the Forum will offer 
project on-boarding rooms! This idea is that these rooms will provide 
a place for new contributors to a given project to find out more about 
the project, people, and code base. The slots will be spread out 
throughout the whole Summit and will be 90 min long.


We have a very limited slots available for interested projects so it 
will be a first come first served process. Let me know if you are 
interested and I will reserve a slot for you if there are spots left.


- Kendall Nelson (diablo_rojo)

[1] 
http://lists.openstack.org/pipermail/openstack-dev/2017-March/113459.html



__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev




__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] Asking Survey for I18n translation platform - Zanata usability

[Ian Y. Choi]

Hello all OpenStackers!

I am Ian from I18n team and I am doing PTL in Pike cycle.

Zanata is an open source translation tool - not only I18n team members 
but also many OpenStack translators

now mainly use Zanata as OpenStack translation platform [2].

Zanata development team wants users to do the following survey to 
collect feedback, but IMO it is not just limited to users.
If you have experienced Zanata on development and/or documentation side, 
then I would like to ask you to take the survey.


Please go to the following URL and participate in answering survey 
questionnaires:


- 
https://docs.google.com/forms/d/e/1FAIpQLSeqxia866yOv1GZEmCqCenzT31RO6gzndJ1w7QetRr6NvGvfQ/viewform?usp=sf_link


According to Zanata team, the survey will close on 6th May.

Note: If someone still remember Transifex and is not familiar with 
Zanata, [3] might be helpful to see

  the background of the migration from Transifex to Zanata.


With many thanks,

/Ian

[1] http://zanata.org/
[2] https://translate.openstack.org
[3] 
http://princessleia.com/journal/2015/09/the-migration-of-openstack-translations-to-zanata/



 Original Message 
Subject:Re: [OpenStack-I18n] Survey for Zanata platform
Date:   Thu, 20 Apr 2017 12:43:33 +1000
From:   Alex Eng 
To: Openstack-i18n Openstack-i18n 



Guys,

Sorry for this, but the updated link for the survey:
https://docs.google.com/forms/d/e/1FAIpQLSeqxia866yOv1GZEmCqCenzT31RO6gzndJ1w7QetRr6NvGvfQ/viewform?usp=sf_link 



On Thu, Apr 20, 2017 at 11:33 AM, Alex Eng > wrote:


   Hi guys,

   As part of our plan to improve Zanata translation platform, it is
   important for us to constantly collect feedback from users to
   understand problems and needs.

   It would be appreciated if you guys can spent few minutes to
   complete the survey

   https://drive.google.com/open?id=1lcbmbJ1snljrd5t_nRyGgDTH7SRWpp6PBKJaq7UiQkM
   



   PS. The survey will be closed on 6/MAY.

   Regards,

   -- 


   ALEX ENG

   SENIOR SOFTWARE ENGINEER, TEam lead

   Red Hat Asia-Pacific Pty Ltd 

   Level 1, 193 North Quay

   Brisbane 4000

   a...@redhat.com  M: +61423353457
IM: aeng

   




--

ALEX ENG

SENIOR SOFTWARE ENGINEER

Red Hat Asia-Pacific Pty Ltd 

Level 1, 193 North Quay

Brisbane 4000

a...@redhat.com  M: +61423353457 
 IM: aeng




___
OpenStack-I18n mailing list
openstack-i...@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-i18n
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [I18n] (Special) Summit hack-room & IRC meeting in this week with Skype

[Ian Y. Choi]

Hello all,

First of all, I really really feel that Boston Summit welcomes translators!
Thanks to lots of kind support from upstream contributors, users,
operators, and also Foundation staff,
I think I18n team is able to have so many I18n sessions during this Summit.

I have asked translators whether they would come to Boston Summit or not
via i18n mailing list
several times but it seems that a few active translators finally have come
to Boston Summit [1].

Now, I would like to propose a hack-room for I18n team
on on Thursday 9:00 AM - 10:30 AM at Hynes, MR 108 (I have signed into [2]).
I think the time would be the best for I18n team since Thursday 9:00 AM -
10:00 AM is the same as I18n IRC meeting time slot [3].

So, for physical Summit attendees:
 - Please attend to I18n hack room on Thursday 9:00 AM - 10:30 AM at Hynes,
MR 108.
 - If someone wants to more know I18n and translation or have questions on
translation,
   please ping me via IRC. My IRC nickname is "ianychoi".

And for I18n translators (+ Zanata development team members) who are unable
to physically attend to the Summit:
- Please come to IRC meeting [3].
- Also I strongly encourage to also join a voice meeting via Skype Business.
  I have made a link for the Meeting:
https://meet.lync.com/ychoi/ianychoi/3HVZ0CY1 .
  Please join in the meeting if you would like to see I18n people in the
Summit :)
- Timezone information is also available at: [4]

Also, I welcome upstream contributors, users, operators, and even
Summit-101 members who would like to know how I18n team is dealing with
translation.

I am now proposing the following topics, but topics may be subject to
change:

 - (Greeting)
 - Sharing how Summit is going with I18n
 - Report of recent Zanata production server error
 - User survey translation status
 - Discussion on I18n team PTG participation
 - Feedback from I18n contributors: PTG, Summit, Design Summit, Forum
 - Action items


With many thanks,

/Ian

[1] https://etherpad.openstack.org/p/i18n-boston-summit-activities
[2] https://ethercalc.openstack.org/Boston_Forum_Hacking_Rooms
[3]
https://wiki.openstack.org/wiki/Meetings/I18nTeamMeeting#Agenda_for_next_meeting
[4]
https://www.timeanddate.com/worldclock/meetingdetails.html?year=2017&month=5&day=11&hour=13&min=0&sec=0&p1=43&p2=47&p3=33&p4=235&p5=108&p6=166
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [I18n] Inviting to Zanata (translation platform) webinar: June 8th at 13:00 UTC

[Ian Y. Choi]

Hello,

I am organizing a webinar by inviting Zanata (OpenStack translation 
platform) development team
as an invited speaker and seeing #openstack-meeting IRC channel for 
questions and answers

on tomorrow (June 8th) 13:00 UTC.

I would like to invite to all who are interested in OpenStack 
translation platform
and which new features I18n team is expecting with a newer version of 
Zanata.



With many thanks,

/Ian

( 
http://lists.openstack.org/pipermail/openstack-i18n/2017-June/002933.html )

 Original Message 
Subject: 	[I18n] Zanata webinar with IRC meeting (qna): June 8th at 
13:00 UTC

Date:   Wed, 7 Jun 2017 14:21:19 +0900
From:   Ian Y. Choi 
To: Openstack-i18n 



Hello,

I am glad to announce that there will be a webinar from Zanata
development team.

- Title: The features since 3.9 in Zanata
- Date & Time: June 8th at 13:00 UTC (presentation will be for 30-40
minutes)
- Invited speaker: Patrick Huang (Senior Software Engineer in Red Hat)
- Presentation description:
  Zanata [1] is an open source translation platform and OpenStack I18n
team [2]
  uses it as a translation platform [3] running upon openstack-infra [4].
  At the moment translate.openstack.org is running Zanata version 3.9.6.
  Here we will have a preview of the new features developed by Zanata
team since 3.9.x.
  This will help us to decide when to upgrade to newer version as well
as better
  utilize the tool once it's upgraded.
- YouTube Live URL: https://www.youtube.com/watch?v=mVCSAfk4t54

During this webinar, I18n IRC meeting (#openstack-meeting freenode IRC
channel)
will be used for questions and answers on the webinar.

Also, I have heard that YouTube Live access might be limited to some
countries.
For that, please tell me for me to prepare a channel with Skype for
Business URL.
Note that the attendees using Skype for Business might be muted.


With many thanks,

/Ian

[1] http://zanata.org/
[2] https://wiki.openstack.org/wiki/I18nTeam
[3] https://translate.openstack.org
[4] http://git.openstack.org/cgit/openstack-infra/puppet-zanata

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Cinder] string freeze exception for VMAX driver

[Ian Y. Choi]

Hello Helen,

Thanks a lot for sharing a string freeze exception request to 
openstack-dev mailing list.


With @amotoki's comment [1] and the discussion on the last IRC meeting 
yesterday [2],
I18n team is fine and there will be no problem to accept the requests 
from I18n team's perspective.


Note that String Freeze has been important for Docs & I18n team to 
acknowledge string freeze
status and take appropriate actions of what needs to be changed to 
documentation and translation activities if needed.
Since I18n team now more focuses on dashboard translations [1] and 
documents are being migrated [3],
I think the importance of string freeze for server projects (e.g., 
cinder, nova, keystone, neutron) might
be less important than previous cycle(s), but sharing the status to all 
the teams including release management team

is a good idea to stay on the same page as much as possible :)


With many thanks,

/Ian, I18n team Ocata PTL.


[1] 
http://lists.openstack.org/pipermail/openstack-i18n/2017-August/002999.html
[2] 
http://eavesdrop.openstack.org/meetings/openstack_i18n_meeting/2017/openstack_i18n_meeting.2017-08-03-13.02.html
[3] 
http://specs.openstack.org/openstack/docs-specs/specs/pike/os-manuals-migration.html


Walsh, Helen wrote on 8/3/2017 5:21 PM:


*To whom it may concern,*

I would like to request a string freeze exception for 2 patches that 
are on the merge queue for Pike.


1.VMAX driver - align VMAX QOS settings with front end  (CI Passed)

https://review.openstack.org/#/c/484885/7/cinder/volume/drivers/dell_emc/vmax/rest.py 
line 800 (removal of exception message)


Although it’s primary aim is to align QoS with front end setting it 
indirectly fixes a lazy loading error we were seeing around QoS which 
occasionally


Broke CI on previous patches.

2.VMAX driver - seamless upgrade from SMI-S to REST (CI Pending)

https://review.openstack.org/#/c/482138/19/cinder/volume/drivers/dell_emc/vmax/common.py 
line 1400 ,1455 (message changes)


This is vital for as reuse of volumes from Ocata to Pike.  In Ocata we 
used SMIS to interface with the VMAX, in Pike we are using REST.  A 
few changes needed to be made to make this transition as seamless as 
possible.


Thank you,

Helen



__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev



__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Cinder] string freeze exception for VMAX driver

[Ian Y. Choi]

Hello Sean,

For soft string freezes as a translator's view, trying the way you 
suggested for server projects would be good assuming that:
- The volume of changes (e.g., the number of sentences, ratio of 
changes) needs to be properly limited
- The string change needs to be well notified to translators (e.g., 
sharing to openstack-i18n mailing list)
- It would be so nice if I18n team can keep track of original string 
changes in Zanata - translate.openstack.org but

  currently it is not easy unfortunately.

For hard string freezes, in my honest opinion, it is difficult to change 
the current policy
because some translation sync support activities for a stable branch in 
openstack-infra [1] and

addition of a stable version in translate.openstack.org [2] are dealt.

From those views, I would like to discuss more opinions and would we 
try better approach from the next development cycle

with agreement for server projects?


With many thanks,

/Ian

[1] 
https://review.openstack.org/#/c/435812/1/jenkins/jobs/projects.yaml@1146

[2] https://translate.openstack.org/iteration/view/cinder/stable-ocata

Sean McGinnis wrote on 8/5/2017 1:42 AM:

I think the importance of string freeze for server projects (e.g., cinder,
nova, keystone, neutron) might
be less important than previous cycle(s), but sharing the status to all the
teams including release management team
is a good idea to stay on the same page as much as possible :)


Hey Ian,

Do you think we should make any changes to our policy for this? Just one thing
that comes to mind, for server projects should we just send out a ML post with
something like "Here is a list of patches we deemed important that had string
translations".

Just thinking of how we can keep things moving when needed while still making
sure important things are communicated well.

Or is that even too much? During soft string freeze, should the server project
core teams just try to be more aware of these but just approve patches that
are important fixes and move on?

Thanks,
Sean

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev




__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [requirements][I18n][OpenStackClient][Quality Assurance][Security][Telemetry][ec2-api][heat][horizon][ironic][kuryr][magnum][manila][monasca][murano][neutron][octavia][senlin][solu

[Ian Y. Choi]

Akihiro Motoki wrote on 8/10/2017 7:22 PM:

Tony,

Thanks for taking care.






i18n   I18n

At now, i18n repo is a part of governance but this is a project which
has no need to cut a release,
so it always follows the master branch of the requirements repo.
It is not a blocker for opening the master branch in the requirements repo.




Right - i18n repository has I18n contributor guide, translation 
glossary, and useful scripts with translate.openstack.org

which all do not need to have stable branches to be maintained.

I am not pretty sure but it seems that some project repositories which 
are affected by requirements.txt in stable branches

need to follow "stable:follows-policy" [1] for official projects?

And also thanks a lot - since I also keep on eyes for having stable 
branches from translation target repositories in Pike release cycle [2].



With many thanks,

/Ian

[1] 
https://governance.openstack.org/tc/reference/tags/stable_follows-policy.html

[2] http://git.openstack.org/cgit/openstack/releases/tree/PROCESS.rst#n214

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [all][I18n] Translations merge

[Ian Y. Choi]

Hello,

Translators are doing translation and translation review activities hard
especially around soft and hard StringFreeze periods, and it is also 
similar during this Pike cycle.


Looking at 
https://review.openstack.org/#/q/status:open+topic:zanata/translations,n,z

I18n team sees many projects that have not imported translations.
Please import the translations to avoid them to be reproposed every day.

Note that I18n team is preparing stable/pike translation sync jobs with 
RC1 creation of Horizon
and plugin projects, and more projects will have stable/pike translation 
sync jobs regarding stable releases.



With many thanks,

/Ian - I18n Pike cycle PTL.

[1] 
http://lists.openstack.org/pipermail/openstack-dev/2017-August/121038.html


__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] PDFs for project-specific docs with unified doc builds

[Ian Y. Choi]

Hello,

"Build PDF docs from rst-based guide documents" [1] was implemented in Ocata
cycle, and I have heard that there were a small conversation at the 
Denver PTG

regarding getting PDFs for project-specific docs setup to help translations.

In my opinion, it would be a nice idea to extend [1] to project-specific
docs with unified doc builds. It seems that unified doc builds have been
much enhanced with [2]. Now I think having PDF build functionalities in 
unified

doc builds would be a way to easily have PDFs for project-specific docs.

Would someone have any idea on this or help it with some good pointers?


With many thanks,

/Ian

[1] 
http://specs.openstack.org/openstack/docs-specs/specs/ocata/build-pdf-from-rst-guides.html
[2] 
http://specs.openstack.org/openstack/docs-specs/specs/pike/os-manuals-migration.html


__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [infra][docs][i18n][ptls] PDFs for project-specific docs with unified doc builds

[Ian Y. Choi]

Hello Doug,

Thanks a lot for the details on unified docs builds for infra side: Your 
links are really helpful

to better point where to implement.

I have first written it as one WIP spec: 
https://review.openstack.org/#/c/509297/
I would like to discuss it in upcoming Docs team IRC meeting and update 
the spec with feedback :)



With many thanks,

/Ian

Doug Hellmann wrote on 9/25/2017 10:50 PM:

[Topic tags added to subject line]

Excerpts from Ian Y. Choi's message of 2017-09-22 07:29:23 +0900:

Hello,

"Build PDF docs from rst-based guide documents" [1] was implemented in Ocata
cycle, and I have heard that there were a small conversation at the
Denver PTG
regarding getting PDFs for project-specific docs setup to help translations.

In my opinion, it would be a nice idea to extend [1] to project-specific
docs with unified doc builds. It seems that unified doc builds have been
much enhanced with [2]. Now I think having PDF build functionalities in
unified
doc builds would be a way to easily have PDFs for project-specific docs.

Would someone have any idea on this or help it with some good pointers?

The job-template for the unified doc build job is in
http://git.openstack.org/cgit/openstack-infra/project-config/tree/jenkins/jobs/openstack-publish-jobs.yaml#n22

It uses the "docs" macro, which invokes the script
http://git.openstack.org/cgit/openstack-infra/project-config/tree/jenkins/scripts/run-docs.sh

I think we would want to place any new logic for extending the build in
that script, although we should coordinate any changes with the Zuul v3
rollout because as part of that I have seen some suggestions to change
the expected interface for building documentation and we want to make
sure any changes we make will work with the updated interface.

Doug

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev




__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [OpenStack-I18n] [I18n] survey about translation of project repo documentation

[Ian Y. Choi]

Hello Frank,

I have just answered the survey - hopefully the survey end time is based 
on UTC

and my survey answer will be also considered well.

If you (developers, translators) are interested in seeing the translated 
version of
project repository documentation, please fill out the survey, which is 
very helpful

for I18n team to have good insight.


With many thanks,

/Ian

Frank Kloeker wrote on 11/9/2017 10:15 PM:

Dear all,

hopefully you had a nice Summit and you're safe at home or on the way 
again.
During the week the I18n team was thinking about documentation 
translating in project repos. The doc migration is almost done and now 
it's a good time to start. But there are a lot's of projects and the 
state of things is different. To get an impression how important this 
topic is and which projects are interested We've create a survey to 
figure it out [1]. Please take part in the survey till 2017/11/15 
23:59:59


many thanks

Frank (PTL I18n)

[1] https://www.surveymonkey.de/r/HSD5YTD

___
OpenStack-I18n mailing list
openstack-i...@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-i18n




__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [all] Changes to releasenotes and docs build jobs

[Ian Y. Choi]

Hello,

Maybe there would be some chance to be also considered with PDF builds?

I created an WIP patch on openstack/horizon repository [1] to highlight
which changes to be needed for PDF build support on docs and releasenotes.

Although there is currently one warning using "python setup.py 
build_sphinx" [2],
I think the warning would be quite fine now since using sphinx-build 
command with
"-b latex" option works well and such command execution is how PTI is 
going from my understanding [3].


(I am also copying this to openstack-docs mailing list for [4].)


With many thanks,

/Ian

[1] https://review.openstack.org/#/c/520620/
[2] https://github.com/sphinx-doc/sphinx/issues/4259
[3] 
http://git.openstack.org/cgit/openstack-infra/zuul-jobs/tree/roles/sphinx/tasks/main.yaml#n15

[4] https://review.openstack.org/#/c/509297/

Doug Hellmann wrote on 11/23/2017 12:05 AM:

Excerpts from Monty Taylor's message of 2017-11-22 07:39:45 -0600:


* We use -W for all releasenotes builds - this means warnings are always
errors for releasenotes. That shouldn't bother anyone, as most of the
releasenotes content is generated by reno anyway.

For projects that never had -W set, there may be invalid RST in old
branches. We hit that in ceilometer for mitaka and newton, and since
those branches were closed already we used "reno report" to generate
static RST pages to replace the reno directives. See
https://review.openstack.org/#/c/521548/ for an example of doing this if
your project has a similar issue.

Doug

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev




__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [OpenStack-docs] [all] Changes to releasenotes and docs build jobs

[Ian Y. Choi]

Thierry Carrez wrote on 11/23/2017 5:38 PM:

Doug Hellmann wrote:

On Nov 22, 2017, at 11:22 AM, Ian Y. Choi  wrote:

Hello,

Maybe there would be some chance to be also considered with PDF builds?

I created an WIP patch on openstack/horizon repository [1] to highlight
which changes to be needed for PDF build support on docs and releasenotes.

Although there is currently one warning using "python setup.py build_sphinx" 
[2],
I think the warning would be quite fine now since using sphinx-build command 
with
"-b latex" option works well and such command execution is how PTI is going 
from my understanding [3].

It does make sense to build PDFs. Do you think we want to always build them?


From now, I have several perspectives:
- Since PDF builds do not require additional modification to existing 
RST documents, always building would be a good idea
 (although few RSTs might have problems - from previous experiences, 
for example, some deprecated usage or

  unsupported unicode characters in font files).
- Some PDF output might be awkward because of image position and table 
layout, but

  those can be easily modified [1].
- Since PDF builds require additional packages in bindep.txt [2], build 
jobs might be slow.






(I am also copying this to openstack-docs mailing list for [4].)

We really really need to stop using that separate mailing list. Now that the 
project teams are managing their own documentation, we should just have the 
docs discussions on the -dev list so everyone can participate.

+1
How about closing that list?



+1

Petr, how do you think about closing that list and encourage current 
openstack-docs subscribers

to use openstack-dev with [docs] tag?


With many thanks,

/Ian

[1] 
https://review.openstack.org/#/c/427826/27/doc/ha-guide/source/networking-ha-l3.rst@16

[2] https://review.openstack.org/#/c/520620/3/bindep.txt

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Openstack] Naming polls - and some issues

[Ian Y. Choi]

Hello,

Today I tried to vote the naming polls for P and Q releases, however, 
unfortunately I am experiencing some issues.


I used the link for P release in the e-mail titled "Poll: OpenStack P 
Release Naming" on July 11 22:42 UTC.

When I click my URL, the poll site says:
"Error / Your voter key is invalid. You should have received a correct 
URL by email."
, and the poll is not ended yet. However I have not received any other 
correct URLs by e-mail.


For Q release, I followed the link in the e-mail: "Poll: OpenStack Q 
Release Naming" on July 12 02:15 UTC.

When I go to my vote URL, the site says "Poll already ended".
But strangely, when I see the poll result ( 
http://civs.cs.cornell.edu/cgi-bin/results.pl?id=E_06e681ae091ad657 ),

all the poll candidates are 'tied'.

So my questions are:

1) Does anybody have troubles on voting P and Q release naming like me?

2) Has the Q release naming poll already finished?
I think it can be finished although the original due date is July 20th. 
However It is so strange that the result I am seeing now is "tied".



With many thanks,

/Ian

Monty Taylor wrote on 7/18/2016 10:03 AM:

Any time is a good time.

On 07/17/2016 04:54 PM, Michael Still wrote:

So, is now a good time to mention that "Quamby" is the name of a local
prison?

Michael



On Fri, Jul 15, 2016 at 7:50 PM, Eoghan Glynn mailto:egl...@redhat.com>> wrote:



 > (top posting on purpose)
 >
 > I have re-started the Q poll and am slowly adding all of you fine folks
 > to it. Let's keep our fingers crossed that it works this time.
 >
 > I also removed Quay. Somehow my brain didn't process the "it would be
 > like naming the S release "Street"" when reading the original names.
 > Based on the naming critera, "Circular Quay" would be a great option for
 > "Circular" - but sadly we already named the C release Cactus. It's
 > possible this choice will make someone unhappy, and if it does, I'm
 > certainly sorry. On the other hand, there are _so_ many awesome names
 > possible in this list, I don't think we'll miss it.

 Excellent, thanks Monty for fixing this ... agreed that the remaining
 Q* choices are more than enough.

 Cheers,
 Eoghan

 > I'll fire out new emails for P once Q is up and going.
 >
 > On 07/15/2016 11:02 AM, Jamie Lennox wrote:
 > > Partially because its name is Circular Quay, so it would be like
 calling
 > > the S release Street for  Street.
 > >
 > > Having said that there are not that many of them and Sydney
 people know
 > > what you mean when you are going to the Quay.
 > >
 > >
 > > On 14 July 2016 at 21:35, Neil Jerram mailto:n...@tigera.io>
 > > >> wrote:
 > >
 > > Not sure what the problem would be with 'Quay' or 'Street' -
 they
 > > both sound like good options to me.
 > >
 > >
 > > On Thu, Jul 14, 2016 at 11:29 AM Eoghan Glynn
 mailto:egl...@redhat.com>
 > > >> wrote:
 > >
 > >
 > >
 > > > >> Hey all!
 > > > >>
 > > > >> The poll emails for the P and Q naming have started
 to go
 > > out - and
 > > > >> we're experiencing some difficulties. Not sure at the
 > > moment what's
 > > > >> going on ... but we'll keep working on the issues
 and get
 > > ballots to
 > > > >> everyone as soon as we can.
 > > > >
 > > > > You'll need to re-send at least some emails, because the
 > > link I received
 > > > > is wrong - the site just reports
 > > > >
 > > > >   "Your voter key is invalid. You should have received a
 > > correct URL by
 > > > >   email."
 > > >
 > > > Yup. That would be a key symptom of the problems. One
 of the
 > > others is
 > > > that I just uploaded 3000 of the emails to the Q poll
 and it
 > > shows 0
 > > > active voters.
 > > >
 > > > I think maybe it needs a nap...
 > >
 > > Any chance we could remove "Quay" from the Q release
 naming poll
 > > before
 > > the links are fixed and the real voting starts?
 > >
 > > Otherwise we risk looking a bit silly, since "Quay" for
 the Q
 > > release
 > > would be somewhat akin to choosing "Street" for the S
 release ;)
 > >
 > > Cheers,
 > > Eoghan
 > >
 > >
  __
 > > OpenStack Development Mailing List (not for usage questions)
 > > Unsubscribe:
 > >
  openstack-dev-requ...@lists.openstack.org?subject:

Re: [openstack-dev] [Openstack] Naming polls - and some issues

[Ian Y. Choi]

Thank you, Joshua and Serguei!

Yep. I might have missed his mentions in this thread.
I am now anticipating his new e-mails for P and Q votes.


With many thanks,

/Ian



Joshua Hesketh wrote on 7/18/2016 1:03 PM:

Hello Ian,

My understanding of it is that you need to receive a new link. Monty 
is slowly sending those out in batches and he hasn't finished. I 
expect he'll email the list once he has finished to confirm so I'd 
suggest holding off until then to check.


Cheers,
Josh

On Mon, Jul 18, 2016 at 1:58 PM, Ian Y. Choi <mailto:ianyrc...@gmail.com>> wrote:


Hello,

Today I tried to vote the naming polls for P and Q releases,
however, unfortunately I am experiencing some issues.

I used the link for P release in the e-mail titled "Poll:
OpenStack P Release Naming" on July 11 22:42 UTC.
When I click my URL, the poll site says:
"Error / Your voter key is invalid. You should have received a
correct URL by email."
, and the poll is not ended yet. However I have not received any
other correct URLs by e-mail.

For Q release, I followed the link in the e-mail: "Poll: OpenStack
Q Release Naming" on July 12 02:15 UTC.
When I go to my vote URL, the site says "Poll already ended".
But strangely, when I see the poll result (
http://civs.cs.cornell.edu/cgi-bin/results.pl?id=E_06e681ae091ad657 ),
all the poll candidates are 'tied'.

So my questions are:

1) Does anybody have troubles on voting P and Q release naming
like me?

2) Has the Q release naming poll already finished?
I think it can be finished although the original due date is July
20th. However It is so strange that the result I am seeing now is
"tied".


With many thanks,

/Ian


Monty Taylor wrote on 7/18/2016 10:03 AM:

Any time is a good time.

On 07/17/2016 04:54 PM, Michael Still wrote:

So, is now a good time to mention that "Quamby" is the
name of a local
prison?

Michael



On Fri, Jul 15, 2016 at 7:50 PM, Eoghan Glynn
mailto:egl...@redhat.com>
<mailto:egl...@redhat.com <mailto:egl...@redhat.com>>> wrote:



 > (top posting on purpose)
 >
 > I have re-started the Q poll and am slowly adding
all of you fine folks
 > to it. Let's keep our fingers crossed that it works
this time.
 >
 > I also removed Quay. Somehow my brain didn't
process the "it would be
 > like naming the S release "Street"" when reading
the original names.
 > Based on the naming critera, "Circular Quay" would
be a great option for
 > "Circular" - but sadly we already named the C
release Cactus. It's
 > possible this choice will make someone unhappy, and
if it does, I'm
 > certainly sorry. On the other hand, there are _so_
many awesome names
 > possible in this list, I don't think we'll miss it.

 Excellent, thanks Monty for fixing this ... agreed
that the remaining
 Q* choices are more than enough.

 Cheers,
 Eoghan

 > I'll fire out new emails for P once Q is up and going.
 >
 > On 07/15/2016 11:02 AM, Jamie Lennox wrote:
 > > Partially because its name is Circular Quay, so
it would be like
 calling
 > > the S release Street for  Street.
 > >
 > > Having said that there are not that many of them
and Sydney
 people know
 > > what you mean when you are going to the Quay.
 > >
 > >
 > > On 14 July 2016 at 21:35, Neil Jerram
mailto:n...@tigera.io>
 <mailto:n...@tigera.io <mailto:n...@tigera.io>>
 > > <mailto:n...@tigera.io <mailto:n...@tigera.io>
<mailto:n...@tigera.io <mailto:n...@tigera.io>>>> wrote:
 > >
 > > Not sure what the problem would be with
'Quay' or 'Street' -
 they
 > > both sound like good options to me.
 > >
 > >
 > > On Thu, Jul 14, 2016 at 11:29 AM Eoghan 

Re: [openstack-dev] [openstack-infra] How to take over a project?

[Ian Y. Choi]

Hello Sangho,

When I see 
https://review.openstack.org/#/admin/projects/openstack/networking-onos,access 
page,
it seems that networking-onos-release group members can create stable 
branches for the repository.


By the way, since the networking-onos-release group has no neutron 
release team group,
I think infra team can help to include neutron release team and neutron 
release team can help to create branches
for the repo if there is no reponse from current networking-onos-release 
group member.



Might this help you?


With many thanks,

/Ian

Sangho Shin wrote on 4/18/2018 2:48 PM:

Hello, Ian

I am trying to add a new stable branch in the networking-onos, 
following the page you suggested.



Create stable/* Branch¶



For OpenStack projects this should be performed by the OpenStack 
Release Management Team at the Release Branch Point. If you are 
managing branches for your project you may have permission to do this 
yourself.


  * Go to https://review.openstack.org/ and sign in
  * Select ‘Admin’, ‘Projects’, then the project
  * Select ‘Branches’
  * Enter |stable/| in the ‘Branch Name’ field, and |HEAD| as
the ‘Initial Revision’, then press ‘Create Branch’. Alternatively,
you may run |git branch stable/  && git push gerrit
stable/|


However, after I login, I cannot see the ‘Admin’ and also I cannot 
create a new branch. Do I need an additional authority for it?

BTW, I am a member of networking-onos-core team, as you know.

Thank you,

Sangho



On 18 Apr 2018, at 9:00 AM, Sangho Shin > wrote:


Ian and Gary,

Thank you so much for your answer.
I will try what you suggested.

Thank you,

Sangho

On 17 Apr 2018, at 7:47 PM, Gary Kotton > wrote:


Hi,
You either need one of the ono core team or the neutron release team 
to add you. FYI 
-https://review.openstack.org/#/admin/groups/1001,members

Thanks
Gary
*From:*Sangho Shin >
*Reply-To:*OpenStack List >

*Date:*Tuesday, April 17, 2018 at 5:01 AM
*To:*OpenStack List >

*Subject:*[openstack-dev] [openstack-infra] How to take over a project?
Dear OpenStack Infra team,
I would like to know how to take over an OpenStack project.
I am a committer of the networking-onos project 
(https://github.com/openstack/networking-onos), 
and I would like to take over the project.

The current maintainer (cc’d) has already agreed with that.
Please let me know the process to take over (or change the 
maintainer of) the project.
BTW, it looks like even the current maintainer cannot create a new 
branch of the codes. How can we get the authority to create a new 
branch?

Thank you,
Sangho
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe:openstack-dev-requ...@lists.openstack.org 
?subject:unsubscribe

http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev






__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev



__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [tc][docs] documenting openstack "constellations"

[Ian Y. Choi]

> >> > So, is the documentation team willing to add the new "constellations"
> >> > repository under their umbrella? Or should we keep it as a TC-owned
> >> > repository for now?
> >>
> >> I'm fine having it as parts of the docs team. The docs PTL should be
> >> part of the review team for sure,
> >>
> >> Andreas
> >
> > Yeah, I wasn't really clear there: I intend to set up the documentation
> > and TC teams as members of the new team, so that all members of both
> > groups can be reviewers of the new repository.
>
> +1 Doug
>
>
I think a new specialty team in Docs team structure would fit well into
this purpose
: https://docs.openstack.org/doc-contrib-guide/team-structure.html

Note that the purpose of including docs core members is mentioned in:
http://lists.openstack.org/pipermail/openstack-docs/2016-June/008760.html .


With many thanks,

/Ian
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [docs][openstack-ansible]

[Ian Y. Choi]

Hello Alex,

Alexandra Settle wrote on 5/9/2018 10:13 PM:


I have had such a great time being a part of something as exciting and 
new as OpenStack, and I hope to continue to lurk in the background of 
IRC like a total weirdo. I hope to perform some super shit karaoke 
with you all in another part of the world :) (who knows, maybe I’ll 
just tag along to PTG’s as a social outing… how cool am I?!)




It was so great for me to work with you during Pike cycle as PTL.
From Pike PTG, thanks to lots of kind help from Documentation team, I 
strongly believe that
I18n team successfully settled Pike and later PTGs with deep 
collaboration of Documentation team :)


I appreciate your so many kind things to me - I learned a lot from your 
wonderful activities.
I really hope that your everything will go well and we all will meet 
again with much better status!



With many thanks,

/Ian

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [I18n] IRC Office hours reminder: June 7th at 13:00-14:00 UTC

[Ian Y. Choi]

Hello all,

I18n team previously had team meetings but decided to have office hours 
instead [1].
Please feel free to come to #openstack-i18n IRC channel and ask and/or 
discuss anything
on translation, internationalization, and/or localization issues on 
projects.


Although I18n PTL is now busy on attending OpenStack Days in Europe by 
the of June [2]
(He makes himself really internationlizated by attending to many offline 
events in Europe!),
I am available this week and can serve as a co-chair with the aggrement 
of I18n PTL :)



With many thanks,

/Ian

[1] 
http://lists.openstack.org/pipermail/openstack-i18n/2018-April/003238.html

[2] http://lists.openstack.org/pipermail/openstack-i18n/2018-May/003239.html


__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [release][ptl] not planning to serve as release PTL for Pike

[Ian Y. Choi]

Thank a lot for your great work on release management team.

Also, I would like to express my appreciation to Doug especially for 
communications with I18n team.
I remember that Doug kindly came to I18n room at Austin Design Summit, 
and we discussed some

release management issues for I18n team.
Moreover, releasenotes translation support would not be possible without 
your kind assistance.



With many thanks,

Doug Hellmann wrote on 1/14/2017 5:00 AM:

I announced this at the release team meeting on 6 Jan, but thought
I should also post to the list as well:  I do not plan to serve as
the Release Management team PTL for the Pike release cycle.

It has been my pleasure to serve as PTL, and we've almost finished
the automation work that I envisioned when I joined the team. Now
I would like to shift my focus to some other projects within the
community.  I will still be an active member of the Release Management
team, helping with new initiatives and reviews for releases.

Doug

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev




__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [I18n] Horizon and Horizon plugins: StringFreeze policies for translation

[Ian Y. Choi]

Hello OpenStack developers!

My name is Ian and I am now serving I18n PTL for Ocata cycle.

For previous releases, I18n team set higher priorities for translations 
on Horizon and Horizon plugins
during Soft and Hard StringFreezes to include user-faced translated 
strings as much as possible within releases.


On the other hand, since Ocata cycle is a little bit short, on the last 
I18n IRC meeting,
I18n team decided to start translations from now although some Horizon 
and Horizon plugin projects might

have not freezed all the strings (Soft StringFreeze) yet.
If some projects still have more strings to be freezed, please tell me 
through this thread and/or call me (@ianychoi)

on #openstack-18n channel.

Also, since just one week during Soft & Hard Freeze is too short for 
translators to complete translating and reviewing strings,

some translation contribution might be after RC1.
I18n team would like to do translations by R-2 week (Feb 06 - Feb 10), 
and I hope that all translations
will be successfully included into releases by RC2 and further 
intermediary / final RCs.


I do not expect a worse situation: for instance, there will be more 
translation in a project during R-2 week

but no further releases will be packed in the corresponding project.

Also, it seems that 
https://wiki.openstack.org/wiki/CrossProjectLiaisons#I18n is out of date.
Please fill out liaison information or I would like to ask about I18n 
liaisons later through PTLs :)



With many thanks,

/Ian


 Original Message 
Subject:[OpenStack-I18n] [StringFreeze] Soft StringFreeze starts!
Date:   Tue, 24 Jan 2017 02:16:24 +0300
From:   Ilya Alekseyev 
To: 	openstack-i...@lists.openstack.org 





Dear language coordinators & translators!

Only four weeks left before Ocata release [1] and I would like to inform 
you that Soft StringFreeze period has come.


Language teams need to focus on Horizon and Horizon-related projects
before all translated strings will be packaged for upcoming release.

According to the dashboard on https://translate.openstack.org, our 
targeted priorities look as follows:


- Dashboard - Horizon (High)
- Dashboard Authorization Page (High)
- neutron-lbaas-dashboard (High)
- Trove Dashboard (Medium)
- Sahara Dashboard (Medium)
- Murano Dashboard (Low)
- Magnum UI (Low)
- Designate Dashboard (Low)

All of those and more additional target projects grouped in [2] in 
*master* branch
and PTL (@ianychoi) will check feature freeze status on projects listed 
above.
He will create a stable version: *stable-ocata* in Zanata for the target 
projects this week.


Although the stable version has not been created yet, but it is highly 
encouraged to translate those projects from now, since StringFreeze 
periods are relatively short during Ocata cycle.


If you have questions, feel free to ask through 
openstack-i...@lists.openstack.org 
<mailto:openstack-i...@lists.openstack.org> mailing list or ask  I18n 
members on Freenode #openstack-i18n channel.



Thank you all for your contribution!

[1] https://releases.openstack.org/ocata/schedule.html
[2] 
https://translate.openstack.org/version-group/view/ocata-dashboard-translation/


Ilya Alekseyev (IRC: adiantum), StringFreeze Manager in Ocata cycle
Ian Y. Choi (IRC: ianychoi), I18n Ocata PTL
___
OpenStack-I18n mailing list
openstack-i...@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-i18n

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [I18n] PTL Candidacy for Pike

[Ian Y. Choi]

Hello,

I am writing to announce my candidacy for I18n Pike PTL.

To retrospect my activities in Ocata cycle,
my overall feeling is that Ocata cycle is really short.
In fact, I acknowledge that most of the action items I wrote in [1]
are still on-going or have not completed yet.
Nevertheless, the followings are some memorable activities which I have
involved with and also would like to continue during upcoming Pike cycle:

* Well summarized action items from Ocata Design Summit [2]
* IRC meeting time change accordingly with two bi-weekly schedules
* Publicizing IRC meeting announcement and logs [3]
* On-going effort on Zanata upgrade with Xenial with infra team
* Clearer communication on translation imports and criteria [4, 5]
* Landing page updates for translated documents
* Co-participation in Pike PTG with Documentation team [6]

I am seeing that there are many upstream translations,
and many I18n team members participate with great and kind help.
I really appreciate their contributions and also the help from
especially Infrastructure team, Documentation team, and Zanata development
team members. I believe that I am able to continue my effort to finish
what I wrote in [1] and make for better I18n.

Please support and encourage me again.


With many thanks,

/Ian

[1] 
https://git.openstack.org/cgit/openstack/election/plain/candidates/ocata/I18n/ianychoi.txt

[2] https://etherpad.openstack.org/p/barcelona-i18n-meetup
[3] https://wiki.openstack.org/wiki/I18N/MeetingLogs
[4] 
http://docs.openstack.org/developer/i18n/reviewing-translation-import.html

[5] http://docs.openstack.org/developer/i18n/infra.html
[6] https://www.openstack.org/ptg


__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] Supporting our global community

[Ian Y. Choi]

Hello,

Thanks a lot for this important message.

As an I18n team contributor and an non-US citizen, I quite agree with 
the note.


FYI: ujuc - I18n Korean language coordinator translated the message into 
Korean language
 => 
https://ujuc.kr/openstack-%EB%B2%88%EC%97%AD-supporting-our-global-community-c5a419757cc7#.h3crayt1i



With many thanks,

/Ian

Jonathan Bryce wrote on 1/30/2017 3:34 AM:

OpenStack is a global open source community. The OpenStack Foundation serves 
members in 180 countries focused on advancing the capabilities and 
accessibility of open infrastructure everywhere. We fundamentally believe 
diversity and collaboration are a powerful force for innovation, and it has 
been amazing to see the product of tens of thousands of people around the world 
over the last 6+ years.

Lauren, Mark and I disagree with the executive order issued by President Trump 
that targets individuals from 7 countries. The order restricts the travel and 
movement of people in a discriminatory way that  results in a restriction on 
access to talent and ideas. It is still unclear how the policies will play out 
and be enforced, but we will be watching, advocating for and supporting our 
community members to the best of our ability.

This executive order will not impact the governance of the Foundation or the 
way the community operates globally. We will continue to support user groups 
and community members that are active in the seven countries named by the 
executive order, alongside our 120+ user groups around the world. However, we 
have two scheduled events in the United States within the next six months that 
will attract a global audience: the PTG (Project Teams Gathering) in Atlanta, 
Feb 20-24, a smaller event that will bring together hundreds of upstream 
contributors, and the OpenStack Summit in Boston, May 8-11, our larger event 
that happens every six months.

This executive order could impact some community members' ability to travel to 
Atlanta and Boston, but unfortunately it is too late at this point to change 
the location of these events. The following three OpenStack Summits, however, 
are now scheduled to occur outside of the United States. The next Summit will 
be in November 2017 in Sydney, Australia and we are working to finalize the 
details so we can announce the following two Summit locations soon.

We’ve already heard from one community member, Mohammed Naser, who is concerned 
that his plans to travel from Canada to Atlanta to attend the PTG may be 
restricted, simply because he a dual citizen of Canada and Iraq.  Mohammed has 
been contributing code to OpenStack since 2011 and is the CEO and Founder of 
Vexxhost. Blocking his travel would serve no purpose and rob the community of a 
valuable contributor during an important event. If you are concerned about the 
impact or have any questions, please don't hesitate to reach out to me at 
jonat...@openstack.org.

Political actions like this highlight the importance of our collective values. 
The Four Opens, the founding principles of our community, exist to ensure the 
free flow of talent and ideas, across geographic, national, organizational or 
other lines that might divide us. We believe in humanity. We believe in 
opportunity. We believe in the power of collaboration across borders, and we 
will continue to carry forward our mission.

We also posted this online: 
https://www.openstack.org/blog/2017/01/supporting-our-global-community/

Jonathan Bryce
Mark Collier
Lauren Sell



__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev




__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [OpenStack-docs] [all] Upstream Training Team meeting at PTG - Are you coming?

[Ian Y. Choi]

Hello Csatari,

The previous meeting in Savannah 3 has been finished. Please come here !  :)


With many thanks,

/Ian

Csatari, Gergely (Nokia - HU/Budapest) wrote on 2/23/2017 2:04 AM:

Hi,
We are waiting in Savannah 1 as there is a meeting still ongoing in 
Savannah 3.

Br,
Gerg0

Sent from Nine 

*From:* Ildiko Vancsa 
*Sent:* Feb 21, 2017 9:05 AM
*To:* OpenStack Development Mailing List (not for usage questions); 
openstack-d...@lists.openstack.org; user-committee
*Subject:* Re: [openstack-dev] [all] Upstream Training Team meeting at 
PTG - Are you coming?


Hi All,

A quick reminder that we will have our face to face gathering on 
__Wednesday (tomorrow) at lunch time (12pm ET)__.


I booked Savannah 3 on the second floor (Lobby level). Please grab a 
lunch box after the morning sessions and join us for lunch if you 
would like to get involved with the Upstream Training and/or new 
contributor on boarding activities.


Thanks and Best Regards,
Ildikó
IRC: ildikov


> On 2017. Feb 15., at 13:16, Ildiko Vancsa  
wrote:

>
> Hi,
>
> We are forming a virtual upstream collaboration training team 
including everyone who’s either helping us out with maintaining and 
improving the training material and/or who are attending the course as 
coaches or mentors.

>
> We are planning to meet at the PTG in person next week on Wednesday 
at lunch time. We picked this slot as our first face to face gathering 
as all of us have project related assignments to drive and sessions to 
attend that makes scheduling a meeting even more challenging.

>
> If you are interested in what we are doing and how we are trying to 
make the on boarding process for new contributors a pleasant 
experience and would like to join our activities meet us there!

>
> The meeting time is __Wednesday (February 22) lunch time__. I will 
share the meeting point next week before the meeting.

>
> If you would like to have a mail reminder prior to the meeting next 
week please reach out to me.

>
> Thanks and Best Regards,
> Ildikó
> IRC: ildikov


__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


___
OpenStack-docs mailing list
openstack-d...@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-docs



__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [docs] Office hours instead of regular docs project meetings?

[Ian Y. Choi]

Hello Petr,

Thanks a lot for dealing with this - I like Docs team office hours :)

I can adjust my availablity to current office hour slots although I live 
in APAC region,
but if there is more demand on APAC-friendly time slot, I would like to 
happily volunteer APAC-friendly Docs team office hour slots.



With many thanks,

/Ian

Petr Kovar wrote on 6/27/2018 11:14 PM:

Hi again,

Haven't got much feedback so far on the meeting format change, so let's
proceed with turning formal docs meetings into office hours, keeping the
same time for now, until we decide to make further adjustments based on the
attendance.

The patch is here:

https://review.openstack.org/#/c/578398/

Thanks,
pk


On Wed, 20 Jun 2018 14:21:57 +0200
Petr Kovar  wrote:


Hi all,

Due to low attendance in docs project meetings in recent months, I'd like
to propose turning regular docs meetings into office hours, like many other
OpenStack teams did.

My idea is to hold office hours every Wednesday, same time we held our
docs meetings, at 16:00 UTC, in our team channel #openstack-doc where
many community members already hang out and ask their questions about
OpenStack docs.

Objections, comments, thoughts?

Would there be interest to also hold office hours during a more
APAC-friendly time slot? We'd need to volunteers to take care of it, please
let me know!

Thanks,
pk

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev




__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [OpenStack-I18n] [I18n] IRC Office hours: 2018/07/05 13:00-14:00 UTC

[Ian Y. Choi]

Hello,

I am also available on today office hour - anyone interested in I18n 
office hours subscribing openstack-dev mailing list is also welcome :)



With many thanks,

/Ian


Frank Kloeker wrote on 7/3/2018 6:30 PM:

Hello,

good to be back. Still sorting emails, messages and things. Let's meet 
on Thursday in our team meeting in the new Office Hour format: 
2018/07/05 13:00-14:00 UTC

If you have anything to share please let us know on wiki page [1]

kind regards

Frank


[1] https://wiki.openstack.org/wiki/Meetings/I18nTeamMeeting

___
OpenStack-I18n mailing list
openstack-i...@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-i18n




__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [i18n] Edge and Containers whitepapers ready for translation

[Ian Y. Choi]

Hello,

When I saw overall translation source strings on container whitepaper, I 
would infer that new edge computing whitepaper
source strings would include HTML markup tags. On the other hand, the 
source strings of edge computing whitepaper
which I18n team previously translated do not include HTML markup tags, 
since the source strings are based on just text format.


I really appreciate Akihiro's work on RST-based support on publishing 
translated edge computing whitepapers, since
translators do not have to re-translate all the strings. On the other 
hand, it seems that I18n team needs to investigate on
translating similar strings of HTML-based edge computing whitepaper 
source strings, which would discourage translators.


That's my point of view on translating edge computing whitepaper.

For translating container whitepaper, I want to further ask the 
followings since *I18n-based tools*
would mean for translators that translators can test and publish 
translated whitepapers locally:


- How to build translated container whitepaper using original 
Silverstripe-based repository?
  https://docs.openstack.org/i18n/latest/tools.html describes well how 
to build translated artifacts for RST-based OpenStack repositories
  but I could not find the way how to build translated container 
whitepaper with translated resources on Zanata.



With many thanks,

/Ian

Jimmy McArthur wrote on 7/17/2018 11:01 PM:

Frank,

I'm sorry to hear about the displeasure around the Edge paper.  As 
mentioned in a prior thread, the RST format that Akihiro worked did 
not work with the  Zanata process that we have been using with our 
CMS.  Additionally, the existing EDGE page is a PDF, so we had to 
build a new template to work with the new HTML whitepaper layout we 
created for the Containers paper. I outlined this in the thread " 
[OpenStack-I18n] [Edge-computing] [Openstack-sigs] Edge Computing 
Whitepaper Translation" on 6/25/18 and mentioned we would be ready 
with the template around 7/13.


We completed the work on the new whitepaper template and then put out 
the pot files on Zanata so we can get the po language files back. If 
this process is too cumbersome for the translation team, I'm open to 
discussion, but right now our entire translation process is based on 
the official OpenStack Docs translation process outlined by the i18n 
team: https://docs.openstack.org/i18n/latest/en_GB/tools.html


Again, I realize Akihiro put in some work on his own proposing the new 
translation type. If the i18n team is moving to this format instead, 
we can work on redoing our process.


Please let me know if I can clarify further.

Thanks,
Jimmy

Frank Kloeker wrote:

Hi Jimmy,

permission was added for you and Sebastian. The Container Whitepaper 
is on the Zanata frontpage now. But we removed Edge Computing 
whitepaper last week because there is a kind of displeasure in the 
team since the results of translation are still not published beside 
Chinese version. It would be nice if we have a commitment from the 
Foundation that results are published in a specific timeframe. This 
includes your requirements until the translation should be available.


thx Frank

Am 2018-07-16 17:26, schrieb Jimmy McArthur:

Sorry, I should have also added... we additionally need permissions so
that we can add the a new version of the pot file to this project:
https://translate.openstack.org/project/view/edge-computing/versions?dswid=-7835 



Thanks!
Jimmy



Jimmy McArthur wrote:

Hi all -

We have both of the current whitepapers up and available for 
translation.  Can we promote these on the Zanata homepage?


https://translate.openstack.org/project/view/leveraging-containers-openstack?dswid=5684 
https://translate.openstack.org/iteration/view/edge-computing/master/documents?dswid=5684 
Thanks all!

Jimmy



__ 


OpenStack Development Mailing List (not for usage questions)
Unsubscribe: 
openstack-dev-requ...@lists.openstack.org?subject:unsubscribe

http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev





__ 


OpenStack Development Mailing List (not for usage questions)
Unsubscribe: 
openstack-dev-requ...@lists.openstack.org?subject:unsubscribe

http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev




__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [i18n] Edge and Containers whitepapers ready for translation

[Ian Y. Choi]

Hello Sebastian,

Korean has also currently 100% translation now.
About two weeks ago, there were a discussion how to include the list of 
translators per translated document.


My proposal is mentioned in [1] - do you think it is a good idea and it 
is under implementation,
or parsing the name of translators in header lines on po files (e.g., 
four lines on [2]) would be better idea?



With many thanks,

/Ian

[1] 
http://eavesdrop.openstack.org/irclogs/%23openstack-i18n/%23openstack-i18n.2018-07-19.log.html#t2018-07-19T15:09:46
[2] 
http://git.openstack.org/cgit/openstack/i18n/tree/doc/source/locale/de/LC_MESSAGES/doc.po#n1


Frank Kloeker wrote on 7/31/2018 6:39 PM:

Hi Sebastian,

okay, it's translated now. In Edge whitepaper is the problem with 
XML-Parsing of the term AT&T. Don't know how to escape this. Maybe you 
will see the warning during import too.


kind regards

Frank

Am 2018-07-30 20:09, schrieb Sebastian Marcet:

Hi Frank,
i was double checking pot file and realized that original pot missed
some parts of the original paper (subsections of the paper) apologizes
on that
i just re uploaded an updated pot file with missing subsections

regards

On Mon, Jul 30, 2018 at 2:20 PM, Frank Kloeker  wrote:


Hi Jimmy,

from the GUI I'll get this link:

https://translate.openstack.org/rest/file/translation/edge-computing/pot-translation/de/po?docId=cloud-edge-computing-beyond-the-data-center 


[1]

paper version  are only in container whitepaper:


https://translate.openstack.org/rest/file/translation/leveraging-containers-openstack/paper/de/po?docId=leveraging-containers-and-openstack 


[2]

In general there is no group named papers

kind regards

Frank

Am 2018-07-30 17:06, schrieb Jimmy McArthur:
Frank,

We're getting a 404 when looking for the pot file on the Zanata API:

https://translate.openstack.org/rest/file/translation/papers/papers/de/po?docId=edge-computing 


[3]

As a result, we can't pull the po files.  Any idea what might be
happening?

Seeing the same thing with both papers...

Thank you,
Jimmy

Frank Kloeker wrote:
Hi Jimmy,

Korean and German version are now done on the new format. Can you
check publishing?

thx

Frank

Am 2018-07-19 16:47, schrieb Jimmy McArthur:
Hi all -

Follow up on the Edge paper specifically:

https://translate.openstack.org/iteration/view/edge-computing/pot-translation/documents?dswid=-3192 


[4] This is now available. As I mentioned on IRC this morning, it
should
be VERY close to the PDF.  Probably just needs a quick review.

Let me know if I can assist with anything.

Thank you to i18n team for all of your help!!!

Cheers,
Jimmy

Jimmy McArthur wrote:
Ian raises some great points :) I'll try to address below...

Ian Y. Choi wrote:
Hello,

When I saw overall translation source strings on container
whitepaper, I would infer that new edge computing whitepaper
source strings would include HTML markup tags.
One of the things I discussed with Ian and Frank in Vancouver is
the expense of recreating PDFs with new translations.  It's
prohibitively expensive for the Foundation as it requires design
resources which we just don't have.  As a result, we created the
Containers whitepaper in HTML, so that it could be easily updated
w/o working with outside design contractors.  I indicated that we
would also be moving the Edge paper to HTML so that we could prevent
that additional design resource cost.
On the other hand, the source strings of edge computing whitepaper
which I18n team previously translated do not include HTML markup
tags, since the source strings are based on just text format.
The version that Akihiro put together was based on the Edge PDF,
which we unfortunately didn't have the resources to implement in the
same format.

I really appreciate Akihiro's work on RST-based support on
publishing translated edge computing whitepapers, since
translators do not have to re-translate all the strings.
I would like to second this. It took a lot of initiative to work on
the RST-based translation.  At the moment, it's just not usable for
the reasons mentioned above.
On the other hand, it seems that I18n team needs to investigate on
translating similar strings of HTML-based edge computing whitepaper
source strings, which would discourage translators.
Can you expand on this? I'm not entirely clear on why the HTML
based translation is more difficult.

That's my point of view on translating edge computing whitepaper.

For translating container whitepaper, I want to further ask the
followings since *I18n-based tools*
would mean for translators that translators can test and publish
translated whitepapers locally:

- How to build translated container whitepaper using original
Silverstripe-based repository?
https://docs.openstack.org/i18n/latest/tools.html [5] describes
well how to build translated artifacts for RST-based OpenStack
repositories
but I could not find the way how to build translated conta

Re: [openstack-dev] [i18n] Edge and Containers whitepapers ready for translation

[Ian Y. Choi]

Hello Frank,

I did not notice the list of project but just from the perspective of 
translation metrics in Stackalytics and Zanata,
whitepaper translation contribution is retrieved from Zanata to 
Stackalytics according to the implementation through 
https://review.openstack.org/#/c/288871/ .


For the perspective on Stackalytics <-> the list of projects, another 
possible solution would be to create "openstack-org" project in Zanata,
migrate edge-computing & container whitepaper into "openstack-org" 
project with different version names, ane

adding "openstack-org" project in Stackalytics for consistency.


With many thanks,

/Ian

Frank Kloeker wrote on 8/7/2018 4:49 PM:
Many thanks, Jimmy! At last I draw your attention to Stackalytics. 
Translation metrics for whitepapers not counted there. Maybe you have 
an advice for https://review.openstack.org/#/c/588965/


kind regards

Frank

Am 2018-08-06 21:07, schrieb Jimmy McArthur:

A heads up that the Translators are now listed at the bottom of the
page as well, along with the rest of the paper contributors:

https://www.openstack.org/edge-computing/cloud-edge-computing-beyond-the-data-center?lang=ja_JP 



Cheers!
Jimmy

Frank Kloeker wrote:

Hi Jimmy,

thanks for announcement. Great stuff! It looks really great and it's 
easy to navigate. I think a special thanks goes to Sebastian for 
designing the pages. One small remark: have you tried text-align: 
justify? I think it would be a little bit more readable, like a 
science paper (German word is: Ordnung)
I put the projects again on the frontpage of the translation 
platform, so we'll get more translations shortly.


kind regards

Frank

Am 2018-08-02 21:07, schrieb Jimmy McArthur:

The Edge and Containers translations are now live.  As new
translations become available, we will add them to the page.

https://www.openstack.org/containers/
https://www.openstack.org/edge-computing/

Note that the Chinese translation has not been added to Zanata at this
time, so I've left the PDF download up on that page.

Thanks everyone and please let me know if you have questions or 
concerns!


Cheers!
Jimmy

Jimmy McArthur wrote:

Frank,

We expect to have these papers up this afternoon. I'll update this 
thread when we do.


Thanks!
Jimmy

Frank Kloeker wrote:

Hi Sebastian,

okay, it's translated now. In Edge whitepaper is the problem with 
XML-Parsing of the term AT&T. Don't know how to escape this. 
Maybe you will see the warning during import too.


kind regards

Frank

Am 2018-07-30 20:09, schrieb Sebastian Marcet:

Hi Frank,
i was double checking pot file and realized that original pot 
missed
some parts of the original paper (subsections of the paper) 
apologizes

on that
i just re uploaded an updated pot file with missing subsections

regards

On Mon, Jul 30, 2018 at 2:20 PM, Frank Kloeker  
wrote:



Hi Jimmy,

from the GUI I'll get this link:

https://translate.openstack.org/rest/file/translation/edge-computing/pot-translation/de/po?docId=cloud-edge-computing-beyond-the-data-center 


[1]

paper version  are only in container whitepaper:


https://translate.openstack.org/rest/file/translation/leveraging-containers-openstack/paper/de/po?docId=leveraging-containers-and-openstack 


[2]

In general there is no group named papers

kind regards

Frank

Am 2018-07-30 17:06, schrieb Jimmy McArthur:
Frank,

We're getting a 404 when looking for the pot file on the Zanata 
API:


https://translate.openstack.org/rest/file/translation/papers/papers/de/po?docId=edge-computing 


[3]

As a result, we can't pull the po files.  Any idea what might be
happening?

Seeing the same thing with both papers...

Thank you,
Jimmy

Frank Kloeker wrote:
Hi Jimmy,

Korean and German version are now done on the new format. Can you
check publishing?

thx

Frank

Am 2018-07-19 16:47, schrieb Jimmy McArthur:
Hi all -

Follow up on the Edge paper specifically:

https://translate.openstack.org/iteration/view/edge-computing/pot-translation/documents?dswid=-3192 


[4] This is now available. As I mentioned on IRC this morning, it
should
be VERY close to the PDF.  Probably just needs a quick review.

Let me know if I can assist with anything.

Thank you to i18n team for all of your help!!!

Cheers,
Jimmy

Jimmy McArthur wrote:
Ian raises some great points :) I'll try to address below...

Ian Y. Choi wrote:
Hello,

When I saw overall translation source strings on container
whitepaper, I would infer that new edge computing whitepaper
source strings would include HTML markup tags.
One of the things I discussed with Ian and Frank in Vancouver is
the expense of recreating PDFs with new translations.  It's
prohibitively expensive for the Foundation as it requires design
resources which we just don't have.  As a result, we created the
Containers whitepaper in HTML, so that it could be easily updated
w/o working with outside design contractors.  I 

Re: [openstack-dev] [i18n] Edge and Containers whitepapers ready for translation

[Ian Y. Choi]

Oh my mistake - document not version. Rewriting:

For the perspective on Stackalytics <-> the list of projects, another 
possible solution would be to create "openstack-org" project in Zanata,
migrate edge-computing & container whitepaper from two different 
projects into "openstack-org" project with different document names, and

adding "openstack-org" project in Stackalytics for consistency.


With many thanks,

/Ian



Ian Y. Choi wrote on 8/8/2018 12:06 AM:

Hello Frank,

I did not notice the list of project but just from the perspective of 
translation metrics in Stackalytics and Zanata,
whitepaper translation contribution is retrieved from Zanata to 
Stackalytics according to the implementation through 
https://review.openstack.org/#/c/288871/ .


For the perspective on Stackalytics <-> the list of projects, another 
possible solution would be to create "openstack-org" project in Zanata,
migrate edge-computing & container whitepaper into "openstack-org" 
project with different version names, ane

adding "openstack-org" project in Stackalytics for consistency.


With many thanks,

/Ian

Frank Kloeker wrote on 8/7/2018 4:49 PM:
Many thanks, Jimmy! At last I draw your attention to Stackalytics. 
Translation metrics for whitepapers not counted there. Maybe you have 
an advice for https://review.openstack.org/#/c/588965/


kind regards

Frank

Am 2018-08-06 21:07, schrieb Jimmy McArthur:

A heads up that the Translators are now listed at the bottom of the
page as well, along with the rest of the paper contributors:

https://www.openstack.org/edge-computing/cloud-edge-computing-beyond-the-data-center?lang=ja_JP 



Cheers!
Jimmy

Frank Kloeker wrote:

Hi Jimmy,

thanks for announcement. Great stuff! It looks really great and 
it's easy to navigate. I think a special thanks goes to Sebastian 
for designing the pages. One small remark: have you tried 
text-align: justify? I think it would be a little bit more 
readable, like a science paper (German word is: Ordnung)
I put the projects again on the frontpage of the translation 
platform, so we'll get more translations shortly.


kind regards

Frank

Am 2018-08-02 21:07, schrieb Jimmy McArthur:

The Edge and Containers translations are now live.  As new
translations become available, we will add them to the page.

https://www.openstack.org/containers/
https://www.openstack.org/edge-computing/

Note that the Chinese translation has not been added to Zanata at 
this

time, so I've left the PDF download up on that page.

Thanks everyone and please let me know if you have questions or 
concerns!


Cheers!
Jimmy

Jimmy McArthur wrote:

Frank,

We expect to have these papers up this afternoon. I'll update 
this thread when we do.


Thanks!
Jimmy

Frank Kloeker wrote:

Hi Sebastian,

okay, it's translated now. In Edge whitepaper is the problem 
with XML-Parsing of the term AT&T. Don't know how to escape 
this. Maybe you will see the warning during import too.


kind regards

Frank

Am 2018-07-30 20:09, schrieb Sebastian Marcet:

Hi Frank,
i was double checking pot file and realized that original pot 
missed
some parts of the original paper (subsections of the paper) 
apologizes

on that
i just re uploaded an updated pot file with missing subsections

regards

On Mon, Jul 30, 2018 at 2:20 PM, Frank Kloeker  
wrote:



Hi Jimmy,

from the GUI I'll get this link:

https://translate.openstack.org/rest/file/translation/edge-computing/pot-translation/de/po?docId=cloud-edge-computing-beyond-the-data-center 


[1]

paper version  are only in container whitepaper:


https://translate.openstack.org/rest/file/translation/leveraging-containers-openstack/paper/de/po?docId=leveraging-containers-and-openstack 


[2]

In general there is no group named papers

kind regards

Frank

Am 2018-07-30 17:06, schrieb Jimmy McArthur:
Frank,

We're getting a 404 when looking for the pot file on the 
Zanata API:


https://translate.openstack.org/rest/file/translation/papers/papers/de/po?docId=edge-computing 


[3]

As a result, we can't pull the po files.  Any idea what might be
happening?

Seeing the same thing with both papers...

Thank you,
Jimmy

Frank Kloeker wrote:
Hi Jimmy,

Korean and German version are now done on the new format. Can you
check publishing?

thx

Frank

Am 2018-07-19 16:47, schrieb Jimmy McArthur:
Hi all -

Follow up on the Edge paper specifically:

https://translate.openstack.org/iteration/view/edge-computing/pot-translation/documents?dswid=-3192 


[4] This is now available. As I mentioned on IRC this morning, it
should
be VERY close to the PDF.  Probably just needs a quick review.

Let me know if I can assist with anything.

Thank you to i18n team for all of your help!!!

Cheers,
Jimmy

Jimmy McArthur wrote:
Ian raises some great points :) I'll try to address below...

Ian Y. Choi wrote:
Hello,

When I saw overall translation sourc

Re: [openstack-dev] [openstack-ansible] Stepping down from OpenStack-Ansible core

[Ian Y. Choi]

Hello Andy,

Thanks a lot for your work on OpenStack-Ansible team.

It was very happy to collaborate with you as different teams (me: I18n 
team) during Ocata and Pike release cycles,
and I think I18n team now has better insight on OpenStack-Ansible thanks 
to the help from you and so many kind contributors.



With many thanks,

/Ian

Andy McCrae wrote on 8/31/2018 2:40 AM:
Now that Rocky is all but ready it seems like a good time! Since 
changing roles I've not been able to keep up enough focus on reviews 
and other obligations - so I think it's time to step aside as a core 
reviewer.


I want to say thanks to everybody in the community, I'm really proud 
to see the work we've done and how the OSA team has grown. I've 
learned a tonne from all of you - it's definitely been a great experience.


Thanks,
Andy


__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev




__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [storyboard] [I18n] Can Storyboard web pages be translatable to multiple languages?

[Ian Y. Choi]

Hello,

I wanna ask whether https://storyboard.openstack.org/ web pages can be
translatable to multiple languages
(e.g., Chinese, Japanese, Korean, German, French, Spanish, ...) or not.

I have thought such idea on my mind from some time period ago, and I
think now would be a good timing
for raising this question since it seems that more project repositories
are migrating to Storyboard,
and internationalization of Storyboard is one of criteria for I18n team
to decide to migrate to Storyboard
(FYI: discussion on I18n team - [1]).

From my very brief investigation, it seems that adding I18n support on
html pages like [2],
extracting translation source strings to pot files, syncing with Zanata
[3] with powerful infra support [4]
would make Storyboard translatable with translating to multiple
languages by I18n team.

Am I understanding correctly and can I18n team get help on such effort?


With many thanks,

/Ian

[1]
http://lists.openstack.org/pipermail/openstack-i18n/2018-September/003307.html
[2]
http://git.openstack.org/cgit/openstack-infra/storyboard-webclient/tree/src/app/stories/template/list.html#n26
[3] http://translate.openstack.org/
[4] https://docs.openstack.org/i18n/latest/infra.html


__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [doc][i18n][infra][tc] plan for PDF and translation builds for documentation

[Ian Y. Choi]

First of all, thanks a lot for nice summary - I would like to deeply
read and put comments later.

And @mtreinish, please see my reply inline:

Matthew Treinish wrote on 9/14/2018 5:09 AM:
> On Thu, Sep 13, 2018 at 07:23:53AM -0600, Doug Hellmann wrote:
>> Excerpts from Michel Peterson's message of 2018-09-13 10:04:27 +0300:
>>> On Thu, Sep 13, 2018 at 1:09 AM, Doug Hellmann 
>>> wrote:
>>>
 The longer version is that we want to continue to use the existing
 tox environment in each project as the basis for the job, since
 that allows teams to control the version of python used, the
 dependencies installed, and add custom steps to their build (such
 as for pre-processing the documentation). So, the new or updated
 job will start by running "tox -e docs" as it does today. Then it
 will run Sphinx again with the instructions to build PDF output,
 and copy the results into the directory that the publish job will
 use to sync to the web server. And then it will run the scripts to
 build translated versions of the documentation as HTML, and copy
 the results into place for publishing.

>>> Just a question out of curiosity. You mention that we still want to use the
>>> docs environment because it allows fine grained control over how the
>>> documentation is created. However, as I understand, the PDF output will
>>> happen in a more standardized way and outside of that fine grained control,
>>> right? That couldn't lead to differences in both documentations? Do we have
>>> to even worry about that?
>> Good question.  The idea is to run "tox -e docs" to get the regular
>> HTML, then something like
>>
>>.tox/docs/bin/sphinx-build -b latex doc/build doc/build/latex
>>cd doc/build/latex
>>make
>>cp doc/build/latex/*.pdf doc/build/html
> To be fair, I've looked at this several times in the past, and sphinx's latex
> generation is good enough for the simple case, but on more complex documents
> it doesn't really work too well. For example, on nova I added this a while 
> ago:
>
> https://github.com/openstack/nova/blob/master/tools/build_latex_pdf.sh

After seeing what the script is doing, I wanna divide into several parts
and would like to tell with some generic approach:

- svg -> png
 : PDF builds ideally convert all svg files into PDF with no problems,
but there are some realistic problems
   such as problems on determining bounding sbox size on vector svg
files, and big memory problems with lots of tags in svg files.
 : Maybe it would be solved if we check all svg files with correct
formatting,
   or if all svg files are converted to png files with temporal changes
on rst file (.svg -> .png), wouldn't it?

- non-latin code problems:
 : By default, Sphinx uses latex builder, which doesn't support
non-latin codes and customized fonts [1].
   Documentation team tried to make use of xelatex instead of latex in
Sphinx configuration and now it is overridden
   on openstackdocstheme >=1.20. So non-latin code would not generate
problems if you use openstackdocstheme >=1.20.

- other things
 : I could not capture the background on other changes such as
additional packages.
   If u provide more background on other things, I would like to
investigate on how to approach by changing a rst file
   to make compatible with pdf builds or how to support all pdf builds
on many project repos as much as possible.

When I test PDF builds on current nova repo with master branch, it seems
that the rst document is too big
(876 pages with error) and more dealing with overcoming memory problems
was needed.
I would like to think how to overcome this, but it would be also nice if
someone shares advices or comments on this.


With many thanks,

/Ian

[1] https://tug.org/pipermail/xetex/2011-September/021324.html
[2] https://review.openstack.org/#/c/552070/5/openstackdocstheme/ext.py@227

> To work around some issues with this workflow. It was enough to get the
> generated latex to actually compile back then. But, that script has bitrotted
> and needs to be updated, because the latex from sphinx for nova's docs no
> longer compiles. (also I submitted a patch to sphinx in the meantime to
> fix the check mark latex output) I'm afraid that it'll be a constant game
> of cat and mouse trying to get everything to build.
>
> I think that we'll find that on most projects' documentation we will need
> to massage the latex output from sphinx to build pdfs.
>
> -Matt Treinish
>
>> We would run the HTML translation builds in a similar way by invoking
>> sphinx-build from the virtualenv repeatedly with different locale
>> settings based on what translations exist.
>>
>> In my earlier comment, I was thinking of the case where a team runs
>> a script to generate rst content files before invoking sphinx to
>> build the HTML. That script would have been run before the PDF
>> generation happens, so the content should be the same. That also
>> applies for anyone using sphinx add-ons, which will be avai

Re: [openstack-dev] [docs][i18n][ptg] Stein PTG Summary

[Ian Y. Choi]

Thanks a lot for nice summary on Docs part especially!
I would like to add an additional summary with more context from I18n
perspective.

Note: I mainly participated in Docs/I18n discussion only on Monday & Tuesday
(not available during Wed - Fri due to conflicts with other work in my
country),
and my summary would be different from current I18n PTL if he have
parcipated in Stein PTG,
but I would like to summarize as I18n ex-PTL (Ocata, Pike) and as one of
active partcipants in Docs/I18n discussion.

Documentation & I18n teams started to have collaborative discussions
from Pike PTG.
Following with Queens & Rocky cycle, I am so happy that Documentation &
I18n teams had tight collaboration
again at Stein PTG for horizontal discussion with sharing issues and
tight collaboration.

More details for I18n issues are available at the bottom part ("i18n
Topics") in:
https://etherpad.openstack.org/p/docs-i18n-ptg-stein

PROJECT DOCUMENTATION TRANSLATION SUPPORT

This year, I18n team actively started to support project documentation
translation [1] and there had progress
on defining documentation translation targets, generatepot infra jobs,
and translation sync on from project repositories to
Zanata for translation sources & from Zanata to project repositories for
translated strings.
[2] and [3] are parts of work I18n team did on previous cycle, and the
final part would be how to support translated documentation publication
aligned with Documentation team, since PDF support implementation is
also related with how to publish PDF files for project repositories.

Although there were so nice discussion during last Vancouver Summit [4],
more generic idea on infra side how to better support translated
documentation & PDF builds and translation
would be needed after some changes on Project Testing Interface which is
used for project documentation builds [5].

[6] is a nice summary from Doug (really appreciated!) for the direction
and plans on PDF and translation builds
by making use of openstack-tox-docs job [7], and I18n team would like to
continue to work with Documentation
and Infrastructure teams on actual implementation suring Stein cycle.

USER SURVEY, TRANSLATING WHITEPAPERS, AND RECOGNITION ON TRANSLATORS

With nice collaboration between Foundation and I18n team, I18n team
started to translate
OpenStack user survey [8] after initial discussion on Pike PTG and, edge
computing whitepaper [9],
and container whitepaer [10] into multiple languages with many language
coordinators and translators.

Those translation effort might be different from Active Technical
Contributor (ATC) recognition
which translators also got for OpenStack project translation and
techical documentation translation [11].
Some translators shared that they would be interested in translating
technical documents but not interested in
OpenStack user survey and other non-technical documents.

I thought that it might be due to different governance (Foundation-led &
official projects with technical committee might be different),
and Active User Contributor (AUC) [12] recognition might be a good idea.
Although I could not discuss in details with User Committee members
during PTG,
Foundation agreed that AUC recognition for such translators would be a
good idea and Melvin,
one of user committee agreed with the idea during a very short conversation.
In my opinion, it would take some time for more discussion and agreement
on detail criteria
(e.g., which number of words might be good aligning with current AUC
recognition criteria), User Committee, and Foundation),
but let's try to move forward on this :)

Also, documentation on detail steps and activities with user survey on
further years and more on whitepapers
would be important, so I18n team will more document how I18n team
members do action with steps like [13].

And some translators shared concerns what there is no I18n in OpenStack
project navigator and map.
It would be also related with recognition on what translators contributed.
Foundation explained that it might be the intention of the purpose of
each artifact
(e.g., OpenStack were designed to show OpenStack components and how
those components interact each other with technical perspective),
and Foundation shared that Foundation would do best to aggregate
scattered definitions (e.g., [14], [15], and somewhere more)
for consistency, and find a nice place for Docs, i18n, Congress, etc...
on the Software/Project Navigator.

TRANSLATING CONTRIBUTOR GUIDE WITH FIRST CONTACT SIG

The detail summary is in [16]. To summarize,
 - I shared I18n process to First Contact SIG members. Participants
acknowledged that
   setting *translation period* would be needed but starting from
initial translation process
   would be a good idea since it is not translated yet
 - Participants think that user groups would be interested in
translating contributor guide.
 - Me will setup translation sync and publication on contributor guide
and Kendall Nelson would kindly
   help e

Re: [openstack-dev] [docs] Nominating Ian Y. Choi for openstack-doc-core

[Ian Y. Choi]

Thanks a lot all for such nomination & agreement!

I would like to do my best after I become doc-core as like what I 
current do,
although I still need the help from so many kind, energetic, and 
enthusiastic OpenStack contributors and core members

on OpenStack documentation and so many projects.


With many thanks,

/Ian

Melvin Hillsman wrote on 9/21/2018 5:31 AM:

++

On Thu, Sep 20, 2018 at 3:11 PM Frank Kloeker <mailto:eu...@arcor.de>> wrote:


Am 2018-09-19 20:54, schrieb Andreas Jaeger:
> On 2018-09-19 20:50, Petr Kovar wrote:
>> Hi all,
>>
>> Based on our PTG discussion, I'd like to nominate Ian Y. Choi for
>> membership in the openstack-doc-core team. I think Ian doesn't
need an
>> introduction, he's been around for a while, recently being deeply
>> involved
>> in infra work to get us robust support for project team docs
>> translation and
>> PDF builds.
>>
>> Having Ian on the core team will also strengthen our
integration with
>> the i18n community.
>>
>> Please let the ML know should you have any objections.
>
> The opposite ;), heartly agree with adding him,
>
> Andreas

++

Frank


__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe:
openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
<http://openstack-dev-requ...@lists.openstack.org?subject:unsubscribe>
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev



--
Kind regards,

Melvin Hillsman
mrhills...@gmail.com <mailto:mrhills...@gmail.com>
mobile: (832) 264-2646


__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev




__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] OpenStack Project Navigator

[Ian Y. Choi]

It would be very nice if the slides of Jimmy's presentation on Wednesday 
during PTG + other slides are shared via this + other (e.g., openstack, 
community, ...) mailing lists.


According to what I discussed with Jimmy on Sep 11, a day before on his 
presentation, and what I learned from seeing some stuff,

I can say that:

- The repo is https://github.com/OpenStackweb/openstack-org and the 
target directory

would be https://github.com/OpenStackweb/openstack-org/tree/master/software
but it definitely seems that data is managed via an external database, 
not a yaml file when I skimmed the repository and sources so briefly.


- Foundation shared that Foundation would do best to aggregate
scattered definitions for consistency, and find a nice place for all 
official projects like Docs, i18n, Congress, etc... on the 
Software/Project Navigator. [1].



With many thanks,

/Ian

[1] 
http://lists.openstack.org/pipermail/openstack-dev/2018-September/134883.html



Michael Johnson wrote on 9/22/2018 9:41 AM:

Jimmy,

Yes, the tags are correct in
https://git.openstack.org/cgit/openstack/governance/tree/reference/projects.yaml
but are not correct in Project Navigator.

I am asking where is the git repository with the Project Navigator
code that creates the "Project Details" section?
I am looking for the Project Navigator source code.

Michael
On Fri, Sep 21, 2018 at 4:22 PM Jimmy McArthur  wrote:

The TC tags are indeed in a different repo: 
https://git.openstack.org/cgit/openstack/governance/tree/reference/projects.yaml

Let me know if this makes sense.

Jimmy

Michael Johnson September 21, 2018 at 4:32 PM
Matt,

I'm a bit confused by your response. I'm not looking for a definition
of the tags, that is very clear.

I'm looking for the source code backing the page that is rendering
which tags a project has.
This code appears to be broken and not rendering the tags correctly
and I wanted to see if I could fix it.

Michael

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Matt Riedemann September 21, 2018 at 3:04 PM


Those are down in the project details section of the page, look to the right 
and there is a 'tag details' column. The tags are descriptive and link to the 
details on each tag.

Michael Johnson September 21, 2018 at 1:11 PM
Thank you Jimmy for making this available for updates.

I was unable to find the code backing the project tags section of the
Project Navigator pages.
Our page is missing some upgrade tags and is showing duplicate "Stable
branch policy" tags.

https://www.openstack.org/software/releases/rocky/components/octavia

Is there a different repository for the tags code?

Thanks,
Michael

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Jimmy Mcarthur September 21, 2018 at 8:59 AM
Following up on my (very brief) talk from the PTG, you can now propose changes 
to the Project Navigator by going to 
https://git.openstack.org/cgit/openstack/openstack-map repository

Once your patch is merged, the page should reflect the changes straight away.

Cheers,
Jimmy

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev




__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] OpenStack Project Navigator

[Ian Y. Choi]

Thanks a lot for sharing presentation slides and more detail explanation,
which are very helpful for me to understand more context.

I thought that the data were in some external database not in the repo, 
and now clearly figure out how it syncs. [1]



With many thanks,

/Ian

[1] 
https://github.com/OpenStackweb/openstack-org/commit/d8d691848a1677c0a96ddd3029bec645dec8e1f7#diff-fbc5b77edab58d4fe24dd4f7644cc62b


Jimmy McArthur wrote on 9/23/2018 2:26 AM:
We ingest the data from yaml files, at least once per day.  We had a 
bug yesterday that was still reading from the old @ttx repo i/o of the 
new openstack-map repo on git.openstack.org.  That might explain some 
of the issues you were seeing with the project details.  I just pushed 
a fix this morning, so let me know if that cleared up the problem.


The code for the software pages on openstack.org can be found here:
https://github.com/OpenStackweb/openstack-org/tree/master/software/code

The yaml that feeds Project Navigator (Project name, project details, 
etc...)

https://git.openstack.org/cgit/openstack/openstack-map

The yaml that feeds the project tags can be found here:
https://git.openstack.org/cgit/openstack/governance/tree/reference/projects.yaml

The slides from the PTG presentation can be found here:
https://drive.google.com/file/d/10D-h9uJ456fphluc478KZUJZew0XiiO-/view?usp=sharing

Let me know if I  can provide additional details.

Thanks,
Jimmy


Michael Johnson 
September 21, 2018 at 7:41 PM
Jimmy,

Yes, the tags are correct in
https://git.openstack.org/cgit/openstack/governance/tree/reference/projects.yaml
but are not correct in Project Navigator.

I am asking where is the git repository with the Project Navigator
code that creates the "Project Details" section?
I am looking for the Project Navigator source code.

Michael

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: 
openstack-dev-requ...@lists.openstack.org?subject:unsubscribe

http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Jimmy McArthur 
September 21, 2018 at 6:21 PM
The TC tags are indeed in a different repo: 
https://git.openstack.org/cgit/openstack/governance/tree/reference/projects.yaml


Let me know if this makes sense.

Jimmy


__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: 
openstack-dev-requ...@lists.openstack.org?subject:unsubscribe

http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Michael Johnson 
September 21, 2018 at 4:32 PM
Matt,

I'm a bit confused by your response. I'm not looking for a definition
of the tags, that is very clear.

I'm looking for the source code backing the page that is rendering
which tags a project has.
This code appears to be broken and not rendering the tags correctly
and I wanted to see if I could fix it.

Michael

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: 
openstack-dev-requ...@lists.openstack.org?subject:unsubscribe

http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Matt Riedemann 
September 21, 2018 at 3:04 PM


Those are down in the project details section of the page, look to 
the right and there is a 'tag details' column. The tags are 
descriptive and link to the details on each tag.


Michael Johnson 
September 21, 2018 at 1:11 PM
Thank you Jimmy for making this available for updates.

I was unable to find the code backing the project tags section of the
Project Navigator pages.
Our page is missing some upgrade tags and is showing duplicate "Stable
branch policy" tags.

https://www.openstack.org/software/releases/rocky/components/octavia

Is there a different repository for the tags code?

Thanks,
Michael

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: 
openstack-dev-requ...@lists.openstack.org?subject:unsubscribe

http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev




__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev



__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] Sharing upstream contribution mentoring result with Korea user group

[Ian Y. Choi]

Hello,

I got involved organizing & mentoring Korean people for OpenStack 
upstream contribution for about last two months,

and would like to share with community members.

Total nine mentees had started to learn OpenStack, contributed, and 
finally survived as volunteers for
 1) developing OpenStack mobile app for better mobile user interfaces 
and experiences
    (inspired from https://github.com/stackerz/app which worked on Juno 
release), and

 2) translating OpenStack official project artifacts including documents,
 and Container Whitepaper ( 
https://www.openstack.org/containers/leveraging-containers-and-openstack/ ).


Korea user group organizers (Seongsoo Cho, Taehee Jang, Hocheol Shin, 
Sungjin Kang, and Andrew Yongjoon Kong)
all helped to organize total 8 offline meetups + one mini-hackathon and 
mentored to attendees.


The followings are brief summary:
 - "OpenStack Controller" Android app is available on Play Store
  : 
https://play.google.com/store/apps/details?id=openstack.contributhon.com.openstackcontroller

   (GitHub: https://github.com/kosslab-kr/openstack-controller )

 - Most high-priority projects (although it is not during string freeze 
period) and documents are
   100% translated into Korean: Horizon, OpenStack-Helm, I18n Guide, 
and Container Whitepaper.


 - Total 18,695 words were translated into Korean by four contributors
  (confirmed through Zanata API: 
https://translate.openstack.org/rest/stats/user/[Zanata 
ID]/2018-08-16..2018-10-25 ):


++---+-+
| Zanata ID  | Name  | Number of words |
++---+-+
| ardentpark | Soonyeul Park | 12517   |
++---+-+
| bnitech    | Dongbim Im    | 693 |
++---+-+
| csucom | Sungwook Choi | 4397    |
++---+-+
| jaeho93    | Jaeho Cho | 1088    |
++---+-+

 - The list of projects translated into Korean are described as:

+-+-+
| Project | Number of words |
+-+-+
| api-site    | 20  |
+-+-+
| cinder  | 405 |
+-+-+
| designate-dashboard | 4   |
+-+-+
| horizon | 3226    |
+-+-+
| i18n    | 434 |
+-+-+
| ironic  | 4   |
+-+-+
| Leveraging Containers and OpenStack | 5480    |
+-+-+
| neutron-lbaas-dashboard | 5   |
+-+-+
| openstack-helm  | 8835    |
+-+-+
| trove-dashboard | 89  |
+-+-+
| zun-ui  | 193 |
+-+-+

I would like to really appreciate all co-mentors and participants on 
such a big event for promoting OpenStack contribution.
The venue and food were supported by Korea Open Source Software 
Development Center ( https://kosslab.kr/ ).



With many thanks,

/Ian

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [horizon] Question on a singular/plural string use in openstack_dashboard

[Ian Y. Choi]

Hello,

Recently, thanks to the help from Andreas, I am investigating on a 
broken job

for the translation import of Horizon project [1].
The actual error message is
: openstack_dashboard/locale/ko_KR/LC_MESSAGES/django.po:8273: a format 
specification for argument 'req' doesn't exist in 'msgstr[0]'


And then I have found that this error was from a string in horizon - 
openstack_dashboard [2]


error_message = ungettext_lazy(
'The requested instance cannot be launched as you only '
'have %(avail)i of your quota available. ',
'The requested %(req)i instances cannot be launched as 
you '

'only have %(avail)i of your quota available.',
count)
params = {'req': count,
  'avail': available_count}

In i18n translation infrastructure, only one of two (for singular and 
plural) strings should be
selected, translated, saved, and finally imported back to Horizon 
project as [1].

However, the first string only used "%(avail)i" string variable,
and the second string used both "%(req)i" and "%(avail)i" string variables.

Since one Korean translator selected the first string, there will be no 
"%(req)i" in Korean po file, which generates such an error.
So my suggestion is to use the same string variables for both two 
strings when we use ungettext_lazy function.


Is it a bug from Horizon? Would it be other issues when we change like
: from 'The requested instance cannot be launched as you only ' to 'The 
requested %(req)i instance cannot be launched as you only '?



[1] 
http://logs.openstack.org/periodic/horizon-propose-translation-update/c038aab/console.html#_2016-09-16_07_37_22_312092
[2] 
http://git.openstack.org/cgit/openstack/horizon/tree/openstack_dashboard/dashboards/project/instances/workflows/create_instance.py#n214



With many thanks,

/Ian

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [I18n] PTL Candidacy

[Ian Y. Choi]

Hello,

I am writing to announce my candidacy for I18n Ocata PTL.

I have participated in OpenStack translations into Korean
since October 2014. At the first time, I was just a Korean
translator and used Transifex, the previous translation platform.
As I got involved more and more, I have experienced and
learned a lot through the kind help from I18n members and also with
many I18n activities. I went to previous two Summits and it was so
happy to meet many I18n members, Zanata members, and Infra team members
offline. I have committed small patches into Infra, openstack-manuals,
and Stackalytics repositories for better integration with I18n.
Now I am an active translator in Korean team, and also an I18n core 
reviewer.

I am currently ranked as the third top contributor in Translations [1],
and I try to leave review comments with details in
openstack/i18n repository [2].

I18n team has become an official project since June last year [3].
Indeed, internationalizing OpenStack makes OpenStack ubiquitous
accessible to much more members all over the world. To accomplish
our team goal, we have done a lot of things including translation
platform and infrastructure with the collaboration of OpenStack teams.
On the other hand, it seems that currently there are still more things
to do with many translators, language coordinators, and also developers.
In my opinion, we need to find ways to more focus on translation qualities,
and keep better track of the change in evolving OpenStack.

I think I18n team is special because team members have different
language backgrounds and experiences. I like this diversity.
I truly believe that we can make good synergy with the diversity.

In the Ocata cycle, I would like to work with I18n members for:

* Translations are our first important aspect in I18n team.
  For better translations, more conversations and discussions
  with various I18n members are needed. Let's consider the ways
  to better communicate with language translators and coordinators.
  I would like to kindly discuss and cooperate with many members
  to share our good practices and improve OpenStack I18n Guide [4].
  Also, translation support in OpenStack I18n Guide will make our
  significant guide internationally accessible.

* Stablizing our on-going work is also important.
  For example, Stackalytics now shows Translations metric.
  However, more tunings are needed such as applying language filter,
  and showing translations on contribution report.
  Also, we need to apply appropriate ways for translators to regard
  as ATCs with an automated manner rather than registering as extra ATCs.

* Let's facilitate I18n and Inter-Project Cross-Project Liaisons [5].
  Lots of members from different project teams helped a lot.
  Since we have such nice Liaisons relationship with other project teams,
  facilitating Liaisons will be able to go for positive progress.
  For example, I really hope that Infrastructure/I18n Liaisons will
  help successfully land several on-going issues including
  translations check site and Zanata upgrade.

I would like to appreciate previous and current great help from
I18n and also many of different team members. Let's continue our effort
for OpenStack to become more universal! One more thing to mention
is that I am not fully familiar with all of aspects in I18n team.
I need help from many members even if I will be nominated for
I18n Ocata PTL. Please support and encourage me for better I18n project.


[1] http://stackalytics.com/?metric=translations
[2] http://stackalytics.com/report/contribution/i18n/90
[3] 
http://lists.openstack.org/pipermail/openstack-i18n/2015-June/001112.html

[4] http://docs.openstack.org/developer/i18n/
[5] https://wiki.openstack.org/wiki/CrossProjectLiaisons#I18n


With many thanks,

/Ian


__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [OpenStack-I18n] [horizon] Question on a singular/plural string use in openstack_dashboard

[Ian Y. Choi]

Thank you, Akihiro-san.

I agree that it is better to use same variables as much as possible.

Akihiro Motoki wrote on 9/19/2016 7:21 AM:

Hi Ian,

gettext itself allows this pattern [1] but django compilemessage
expects variables with same names are used in all plural forms (See
Note in [2]).
IMHO it is better to use same variables in all plural forms in code as
possible as we can.
As translator, I try to use the second pattern (i.e., plural form) as
source string as a plural form contains sufficient and full pattern in
most cases.
Yep it would be a Fuzzy form for translation in Zanata, but that's okay 
for me. I have fixed in Korean,

and checked that there is no error for 'msgfmt --check-format ' command.


With many thanks,

/Ian

What I am not sure is this happens only for languages with nplural==1
(like Korean, Japanese and so on).

Akihiro

[1] 
https://www.gnu.org/software/gettext/manual/html_node/Translating-plural-forms.html#Translating-plural-forms
[2] 
https://docs.djangoproject.com/en/1.10/topics/i18n/translation/#pluralization


2016-09-16 18:57 GMT+09:00 Ian Y. Choi :

Hello,

Recently, thanks to the help from Andreas, I am investigating on a broken
job
for the translation import of Horizon project [1].
The actual error message is
: openstack_dashboard/locale/ko_KR/LC_MESSAGES/django.po:8273: a format
specification for argument 'req' doesn't exist in 'msgstr[0]'

And then I have found that this error was from a string in horizon -
openstack_dashboard [2]

 error_message = ungettext_lazy(
 'The requested instance cannot be launched as you only '
 'have %(avail)i of your quota available. ',
 'The requested %(req)i instances cannot be launched as you '
 'only have %(avail)i of your quota available.',
 count)
 params = {'req': count,
   'avail': available_count}

In i18n translation infrastructure, only one of two (for singular and
plural) strings should be
selected, translated, saved, and finally imported back to Horizon project as
[1].
However, the first string only used "%(avail)i" string variable,
and the second string used both "%(req)i" and "%(avail)i" string variables.

Since one Korean translator selected the first string, there will be no
"%(req)i" in Korean po file, which generates such an error.
So my suggestion is to use the same string variables for both two strings
when we use ungettext_lazy function.

Is it a bug from Horizon? Would it be other issues when we change like
: from 'The requested instance cannot be launched as you only ' to 'The
requested %(req)i instance cannot be launched as you only '?


[1]
http://logs.openstack.org/periodic/horizon-propose-translation-update/c038aab/console.html#_2016-09-16_07_37_22_312092
[2]
http://git.openstack.org/cgit/openstack/horizon/tree/openstack_dashboard/dashboards/project/instances/workflows/create_instance.py#n214


With many thanks,

/Ian

___
OpenStack-I18n mailing list
openstack-i...@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-i18n




__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [all][i18n] how to indicate non-translatable identifiers in translatable strings?

[Ian Y. Choi]

Hello,

I am from I18n team. Please see inline for my comments.


Doug Hellmann wrote on 11/3/2016 2:19 AM:

Excerpts from Brian Rosmaita's message of 2016-11-02 16:34:45 +:

This issue came up during a code review; I've asked around a bit but
haven't been able to find an answer.

Some of the help output for utility scripts associated with Glance aren't
being translated, so Li Wei put up a patch to fix this [0], but there are
at least two problematic cases.

Case 1:
 parser.add_option('-S', '--os_auth_strategy', dest="os_auth_strategy",
 metavar="STRATEGY",
 help=_("Authentication strategy (keystone or noauth)."))

For that one, 'keystone' and 'noauth' are identifiers, so we don't want
them translated.  Would putting single quotes around them like this be
sufficient to indicate they shouldn't be translated?  For example,

 help=_("Authentication strategy ('keystone' or 'noauth').")


Andreas Jaeger mentioned that maybe we could use a "translation comment"
[1].  I guess we'd do something like:

 # NOTE: do not translate the stuff in single quotes
 help=_("Authentication strategy ('keystone' or 'noauth').")

The ability to pass comments to the translators like that seems
really useful, if it would work with our tools.

+1 from me and also Daisy (former i18n PTL).

I18n team quite agrees what adding translation comments can pass more 
information to translators from developers.



It seems like things we put in quotes should not be translated, by
convention.

I agree with Doug, and Brant's suggestion also looks nice.

To slightly revise from Brant's suggestion, the following original 
string for translation looks much better:


 : "Authentication strategy (%(keystone)s or %(noauth)s).")

 -> %(keystone)s and %(noauth)s will be replaced with "'keystone'" and 
"'noauth'" correspondingly.





What are other people doing for this?

Case 2:
We've got a big block of usage text, roughly

 usage = _("""
%prog  [options] [args]

Commands:
 keyword1what it does
 keyword2what it does
 ...
 keyword8what it does
""")

We don't want the keywords to be translated, but I'm not sure how to
convey this to the translators.

This is a case where using quotes won't work. Using a different
tool to build the help text (argparse instead of optparse), or even
just building the text from parts inline (put the parts you do or
do not want translated into separate variables and then combine the
results like a template) might work. Both add a bit of complexity.
The second option doesn't require completely rewriting the CLI
processing logic.
I think translators easily capture the context of this kind of command 
help strings.


After my brief research on other projects, GNU coreutils also do the 
same way for extracting translation strings

(e.g., http://git.savannah.gnu.org/cgit/coreutils.git/tree/src/ls.c#n4882 ).

For command help strings, translators will prefer not to divide one 
overall string into multiple line-by-line strings,
for example:_("""%prog  [options] [args]""") + "\n" + 
_("""Commands:""") + "\n" + _("""  keyword1  what it does""") .



By the way, can i18n team set any rules within the team,
for example, "don't translate any words in capital.", "If developers 
don't want to translate some words, write them in capital.", and so on?


What do developers think about this idea?


With many thanks,

/Ian


Thanks in advance for your help,
brian


[0] https://review.openstack.org/#/c/367795/8
[1] http://babel.pocoo.org/en/latest/messages.html#translator-comments


__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev




__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [i18n] [glance] ESL question 'shared' vs 'shareable'

[Ian Y. Choi]

Hello devs,

As a Korean translator, I also quite agree with the idea.
Some images with "shared" state but actually not shared yet would be 
awkward,

and "shareable" word would cover such context
: those images can be shard but may not be shared yet (although the 
addition of "image members"is needed)

  or already shared.


Hello translators,

I am copying openstack-i...@lists.openstack.org on this.
Would you pleased think about this and share your thoughts?
(Or please attend to the next i18n IRC meeting about in 9-10 hours and 
tell me.)



With many thanks,

/Ian


Sean McGinnis wrote on 11/17/2016 1:44 AM:

On Wed, Nov 16, 2016 at 04:04:52PM +, Brian Rosmaita wrote:

Hello Translators,

We're having a discussion about a new image "visibility" value for Glance,
and before we go too far, it would be helpful to know whether what we're
worried about is going to matter for ESL people.

Here's the situation: Since the Diablo release, Glance end users have had
the ability to share images with other cloud users by adding "members" to
the image.  We call those "shared images".  Previously, we haven't had a
special "visibility" keyword for these, but we are introducing one now
[0].  Here's the problem introduced by that change:

(1) Members can only be added to an image if its current visibility value
allows for it. We're going to make this an explicit visibility state that
we ware proposing to call 'shared'.

(2) An image with visibility == 'shared', however, isn't actually
accessible to other users unless they are added as "image members".  So
it's going to be possible for a user to have some images with visibility
== 'shared', but they aren't *really* shared with anyone yet.

(3) For reasons outlined on [0], we're proposing to make this new
visibility the default value in Glance.  This will enable the current
sharing workflow to work in a backward-compatible way.  But some people
are worried that users will panic when they see that their new images have
visibility == 'shared' (even though no other users have access to such
images until "image members" are added).

(4) To address this, we're thinking that maybe the identifier for this
kind of image visibility should be 'shareable'.

Finally, here's my question.  For an ESL person looking at these two
identifiers (which, as identifiers, won't be translated):
* shared
* shareable

Are the above so similar that the nuances of the discussion above would be
lost anyway?  In other words, are we just bikeshedding here, or is there a
clear distinction?  What I mean is, is the panic described above likely or
unlikely to happen for an ESL person?

thanks,
brian

Good question. I think technically it would be shareable, which would
mean that it then able to be shared.

Realistically though, in my opinion, calling it shared to denote that it
_can be_ shared is probably intuitive enough that there wouldn't be any
confusion about the naming.

My 2 cents.


[0] https://review.openstack.org/#/c/396919/


__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev




__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [all][tc] Exposing project team's metadata in README files

[Ian Y. Choi]

Hello Flavio,

I have two questions on this thread:

1) I have just written my review on training-guides repository
: https://review.openstack.org/#/c/402607/1 .
Then would you revise your initialized patchset by yourself? Or Your 
intention
would be to discuss more on each repository team members and revise 
patch(es) by themselves?


2) Can I18n team (openstack/i18n and openstack/i18n-specs) have such 
image tag? :)



With many thanks,

/Ian

Flavio Percoco wrote on 11/25/2016 11:00 PM:

On 25/11/16 13:46 +, Amrith Kumar wrote:

Flavio,

I see a number of patches[1] which have been landed on this project 
but I find
that at least the ones that were landed for Trove, and a random 
sampling of

the others all to be different from what you proposed below[2] in one
important aspect.

In [2] you proposed a structure where the title of the document; or 
the first,
and most prominent heading, would be the existing heading of the 
document, and

the tags would be below that. In [2] for example, that was:

"kombu - Messaging library for Python"

and the tags would be in smaller font below that.


Hey Amrith,

One reason it's different from Kombu is because Kombu uses shields as 
a backend
for this SVGs, whereas we don't. We generate the badges ourselves[0], 
which

probably ended up in some differences.

The other main difference in the kombu case, there are multiple images 
in the
README, wherease in our case there's one SVG containing multiple svgs. 
The

motivation behind this is being able to update the badges without sending
patches to projects everytime the governance repo is modified.

This layout and format can of couse be modified, the font size and 
family can be

changed, etc. See[1].


What I see in [3] the patch for Trove and the proposed example [4] is:

"Team and repository tags" as the first, and most conspicuous header, 
and the

header "Trove" below that.

In some cases the second header is the same font as the "Team and 
repository

tags" header.


I explained this a bit here[2]. The reason for prepending these secion 
to the

README's instead of finding a good place in it is that READMEs throughout
OpenStack are quite different from each other and putting this at the 
top helped

in making the process of adding the badges simpler.

I think this change (these 124 changes) as proposed are not 
consistent with
the proposal you made below, and certainly seem to be less suitable 
than that
proposal. The end product for the four trove repositories [4], [5], 
[6], and

[7]

I think we should have a discussion on the ML whether we feel that 
this new

structure is the appropriate one, and before some projects approve these
changes and others don't that these be all marked WF-1.


I honestly don't think the current proposal is bad, it's different 
from Kombu
for the reasons I mentioned above but it can be improved. Not that 
improving the
badges and their layout doesn't require submitting these patches 
again. It'll be

enough to modify the governance repo that generates these images.

Hope this helps,
Flavio


[0] 
http://git.openstack.org/cgit/openstack/governance/tree/doc/source/_exts/badges.py

[1] https://review.openstack.org/#/c/399278/
[2] 
http://lists.openstack.org/pipermail/openstack-dev/2016-November/107969.html



Thanks,

-amrith

[1] https://review.openstack.org/#/q/topic:project-badges
[2] https://github.com/celery/kombu/blob/master/README.rst
[3] https://review.openstack.org/#/c/402547/
[4] https://gist.github.com/anonymous/4ccf1cc6e531bb50e78cb4d64dfe1065
[5] https://gist.github.com/1f38def1c65c733b7e4cec3d07399e99
[6] https://gist.github.com/2f1c6e9b800db6d4a49d46f5b0623c1d
[7] https://gist.github.com/9e9e2e2ba4ecfdece7827082114f8258





-Original Message-
From: Flavio Percoco [mailto:fla...@redhat.com]
Sent: Thursday, October 13, 2016 7:07 AM
To: OpenStack Development Mailing List (not for usage questions)

Subject: Re: [openstack-dev] [all][tc] Exposing project team's 
metadata in

README files

On 12/10/16 11:01 -0400, Doug Hellmann wrote:
>Excerpts from Flavio Percoco's message of 2016-10-12 14:50:03 +0200:
>> Greetings,
>>
>> One of the common complains about the existing project organization
>> in the big tent is that it's difficult to wrap our heads around the
>> many projects there are, their current state (in/out the big 
tent), their

tags, etc.
>>
>> This information is available on the governance website[0]. Each
>> official project team has a page there containing the information
>> related to the deliverables managed by that team. Unfortunately, I
>> don't think this page is checked often enough and I believe it's not
>> known
by everyone.
>>
>> In the hope that we can make this information clearer to people
>> browsing the many repos (most likely on github), I'd like to propose
>> that we include the information of each deliverable in the readme
>> file. This information would be rendered along with the rest of the
>> readme (at least on Github, which mig