Hi,

I would like to comment before going to bed :-)

Japanese team discussed the same thing during Horizon translation review this weekend.
See my comment inline.

2015-10-06 2:01 GMT+09:00 Andreas Jaeger <aj@suse.com>:
On 10/05/2015 06:54 PM, Ian Y. Choi wrote:
Hello,

Sorry if I am asking an already discussed issue.

I am now reviewing horizon > stable-liberty > Documents (ko-KR)
  > openstack_dashboard/locale/django before our freezing deadline, as
Daisy mentioned.

But I have found that some Korean strings still have an error with the
following message like:
  "Not enough lines in translation (expected 4, found 3)".

 Akihiro, is this something you could look at in Horizon? Does horizon really need these as separate lines - or is that formatted automatically? Can we do something in horizon here to avoid these problems?

I don't see any problems in this situation.
They are formatted automatically according to a regular HTML rendering rules.

What I can say is that this is a limitation of Django or underlying string extraction tool.
Django manage.py makemessage subcommand (which extracts translatable strings from sources codes and templates)
preserves newlines and spaces even though they have no meaning after rendering templates.
Hopefully Django tool deals with these strings into a single line (though it may be a hard thing) from the point of view of translators :-)


Ian, I think this is fine, I don't see errors in the downloaded po files for Korean.

The only error that msgfmt produces is if the original text has after the last line some white space - and you do not copy that.

On the other hand, it is not productive to insert newlines just to avoid error warning from Zanata.
Zanata prevents reviewers from approving translations when there is such error,
and we cannot complete reviews :-(

# Japanese team insert meaningless newlines to avoid warnings for Liberty translations
# but would not like to do that in the future.

 


The main reason I think is that in our previous translation platform
Transifex,
truncating the last empty line was recommended as far as I remember.
(If not, Transifex generated an error.)

My question is: should we fix those error translated strings with same
number of lines and same spaces?
I think it would be ignored because when I see Chinese translation,
there were the same type of
error message for almost translated strings.
(Screenshot:
https://www.dropbox.com/s/bvd098wsakpi192/Zanata_horizon_translation_example_in_zh-CN.png?dl=0
)

And if this error would be negligible to us, are there some ways not to
see this type of errors?

 Zanata allows to disable/enable some checks, but I think this error is nothing we can enable/disable. so, might be worth a feature request to the Zanata team.

This kind of check is sometimes useful and sometimes not.
At the current configuration of Zanata, it seems a global configuration and translators cannot control the option.

Thanks,
Akihiro
 


I would like to copy an example sentence string in Zanata from Korean
for my better explanation.

<in English>(Translated from)
===
First, select which type of job that
                             you want to run.  This choice will
determine which
                             other steps are required

===

<in Korean>(Translated to)
===
먼저, 실행하고자 하는 job 유형
을 선택합니다. 이 선택을 통해 필요로 하는 다른
과정들을 결정할 것입니다.
===


 Thanks, this is a good point to bring up!

Andreas
--
 Andreas Jaeger aj@{suse.com,opensuse.org} Twitter/Identica: jaegerandi
  SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
   GF: Felix Imendörffer, Jane Smithard, Graham Norton,
       HRB 21284 (AG Nürnberg)
    GPG fingerprint = 93A3 365E CE47 B889 DF7F  FED1 389A 563C C272 A126



_______________________________________________
Openstack-i18n mailing list
Openstack-i18n@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-i18n