Open Stack

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 at 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 at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-i18n
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-i18n/attachments/20151006/eed55c48/attachment-0001.html>