Bug 138902 - Impress Presenter Console Help Screen Text Doesn't Wrap Properly (Affected languages: zh_CN/zh_TW)
Summary: Impress Presenter Console Help Screen Text Doesn't Wrap Properly (Affected la...
Status: RESOLVED FIXED
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Impress (show other bugs)
Version:
(earliest affected)
7.1.1.2 release
Hardware: All All
: medium trivial
Assignee: Not Assigned
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2020-12-14 16:17 UTC by tiansworld
Modified: 2021-08-17 07:12 UTC (History)
1 user (show)

See Also:
Crash report or crash signature:


Attachments
Screenshot of the problems (374.14 KB, image/png)
2020-12-14 16:30 UTC, tiansworld
Details
Translation on the top can't be fully displayed. (331.92 KB, image/png)
2021-03-11 09:33 UTC, tiansworld
Details
Fixed (334.09 KB, image/png)
2021-05-19 09:22 UTC, tiansworld
Details
zh_TW has the problem also (326.28 KB, image/png)
2021-05-19 09:52 UTC, tiansworld
Details

Note You need to log in before you can comment on or make changes to this bug.
Description tiansworld 2020-12-14 16:17:45 UTC
Description:
1. Some translated Chinese characters stay outside of the Help frame of presenter console in LibreOffice Impress.
2. In the same area, the style of some translated strings are not consistent with other similar strings.


Steps to Reproduce:
1. Enable presenter console from Preferences -- LibreOffice Impress.
2. Change UI language to Simplified Chinese.
3. Attach an external display device and use it as a separate display.
3. Start slide show
4. Presenter Console starts, then click on the Help button on the right of the 
 console dock.
5. Help displays, and the translated strings can be seen.

Actual Results:
1. The translation of the first two lines on the top left of the frame are out of the frame border. 
2. The single quotes remain in the last translated string ctrl+'4', however the previous ctrl+3 ,ctrl+2, etc. don't contain single quotes.
3. 白屏、取消白屏 is not in accordance with 黑屏/取消黑屏  

Expected Results:
1. The translation should be within the frame border.
2. The single quotes of ctrl+'4' should be deleted.
3. It will be better to use 白屏/取消白屏, which keeps the style in context.


Reproducible: Always


User Profile Reset: No



Additional Info:
Version: 7.0.3.1
Build ID: d7547858d014d4cf69878db179d326fc3483e082
Comment 1 tiansworld 2020-12-14 16:30:44 UTC
Created attachment 168156 [details]
Screenshot of the problems
Comment 2 Ming Hua 2020-12-15 08:32:27 UTC
Thanks for the report.

(In reply to tiansworld from comment #0)
> Expected Results:
> 1. The translation should be within the frame border.
> 2. The single quotes of ctrl+'4' should be deleted.
> 3. It will be better to use 白屏/取消白屏, which keeps the style in context.
I've fixed (2) and (3) in Weblate:

https://weblate.documentfoundation.org/translate/libo_ui-master/officecfgregistrydataorgopenofficeoffice/zh_Hans/?checksum=53bf3be118f2c17
https://weblate.documentfoundation.org/translate/libo_ui-master/officecfgregistrydataorgopenofficeoffice/zh_Hans/?checksum=61a7175415d953b7

For (1) and the inconsistency of the descriptions of the keystrokes, it's not exactly easy to make concise and clear translations here that both fit and screen and is easy for Chinese users to understand.  Besides what you pointed out in your screenshot, "主页" and "终止" are not great translations for "Home" and "End" keys either...

I need more time to think about how to best translate these.  Suggestions welcome.
Comment 3 tiansworld 2020-12-15 09:12:23 UTC
Thanks for the fix.

The "enter" and "return" both mean "回车(键)",and some of the translations omit "键" because we all know that. The "right click" in the nearby string is already translated into "右击". So I would suggest a translation like this:

左击、右/下箭头、空格、向下翻页、回车、N 键

However this still won't fix the problem. It's still too long to be shown within one line.
It's not clear that why the translation won't wrap automatically, but the original English string does.

What about break the line mandatorily?

By the way, I suggest「 」 should be replaced to quotes or deleted.
For example “B” 和 “.” 键 for 'B', '.'.
Comment 4 Ming Hua 2020-12-15 23:46:23 UTC
(In reply to tiansworld from comment #3)
> The "enter" and "return" both mean "回车(键)",and some of the translations omit
> "键" because we all know that. The "right click" in the nearby string is
> already translated into "右击". So I would suggest a translation like this:
> 
> 左击、右/下箭头、空格、向下翻页、回车、N 键
> [...]
> 
> By the way, I suggest「 」 should be replaced to quotes or deleted.
> For example “B” 和 “.” 键 for 'B', '.'.

Thanks for the suggestion.  I decided to keep the word 键 for most entries, except where key-combo is used.  Also decided to use English key names unless there is a well-known Chinese name (i.e., only for Enter, Backspace, Space, and arrow keys).

As for the quotation marks, it's a convention that all simplified Chinese translation of LibreOffice UI use 「/」 pair instead of “/” pair, because the latter has different character width in different platforms or with different font settings.  The quotation marks are rather useless here though, so I just omitted them.

In the end, I decided to go with the following translations for the keys:

鼠标左键,右/下箭头、空格、Page Down、回车 (换行)、或 N 键
鼠标右键,左/上箭头、Page Up、退格、或 P 键
Home 键
End 键
Alt+PageUp
Alt+PageDown
B 和 . 键
W 和 , 键
Esc 或 - 键
输入数字后按回车键
G 和 S 键
A 和 Z 键
H 和 L 键
Ctrl+1
Ctrl+2
Ctrl+3
Ctrl+4

Any corrections?

> However this still won't fix the problem. It's still too long to be shown
> within one line.
> It's not clear that why the translation won't wrap automatically, but the
> original English string does.
> 
> What about break the line mandatorily?
Chinese don't use spaces in sentences, and LO (the ICU library it uses for international text processing, to be exact) is known to have problem with line-breaking here and there.  Since English can line-wrap just fine, hopefulling the spaces I introduced for the two long lines will make the Chinese text also line-wrap.
Comment 5 tiansworld 2020-12-16 02:14:29 UTC
(In reply to Ming Hua from comment #4)

> 鼠标左键,右/下箭头、空格、Page Down、回车 (换行)、或 N 键
> 鼠标右键,左/上箭头、Page Up、退格、或 P 键
> Home 键
> End 键
> Alt+PageUp
> Alt+PageDown
> B 和 . 键
> W 和 , 键
> Esc 或 - 键
> 输入数字后按回车键
> G 和 S 键
> A 和 Z 键
> H 和 L 键
> Ctrl+1
> Ctrl+2
> Ctrl+3
> Ctrl+4
> 
> Any corrections?
> 

They are better. 
In my view, I'd like to remove the (换行) too.

鼠标左键,右/下箭头、空格、Page Down、回车 (换行)、或 N 键

I'm afraid that the space between Page and Down, or 回车 (换行) will make the string less readable if the line break happens at there.

So when considering line break by using the space, what about using the original commas and spaces? Like this:

鼠标左键, 右/下箭头, 空格, PageDown, 回车, 或 N 键

The reason I prefer PageDown not Page Down is to let people aware it is a key name. Also in case of line breaking, it will not break from there. Many keyboards even come with 'Pg Dn/Pg Up' or 'PgUp/PgDn'.

Any way, the above is just my idea. The only way is to test either of them on a machine.
Comment 6 Ming Hua 2020-12-16 10:38:53 UTC
(In reply to tiansworld from comment #5)
> In my view, I'd like to remove the (换行) too.
I'd rather keep it as the English text lists "enter" and "return" separately, and both terms are used in Chinese as well.

> 鼠标左键,右/下箭头、空格、Page Down、回车 (换行)、或 N 键
> 
> I'm afraid that the space between Page and Down, or 回车 (换行) will make the
> string less readable if the line break happens at there.
> 
> So when considering line break by using the space, what about using the
> original commas and spaces? Like this:
> 
> 鼠标左键, 右/下箭头, 空格, PageDown, 回车, 或 N 键
> 
> The reason I prefer PageDown not Page Down is to let people aware it is a
> key name. Also in case of line breaking, it will not break from there. Many
> keyboards even come with 'Pg Dn/Pg Up' or 'PgUp/PgDn'.
I deliberately used more spaces than necessary to mitigate the "no line wrap" problem.  In my opinion it's better to break the line in the middle of the phrase than no line-break at all (and therefore some text not displayed).  Using half-width (western) commas is an option but it deviates from LO UI translation's convention and I'd rather not do it.

> Any way, the above is just my idea. The only way is to test either of them
> on a machine.
I don't have a dual-monitor setup to test, and will have to wait for further feedback from you.  Meanwhile let's mark this bug as RESOLVED (MOVED because the changes are made in Weblate, just a detail you don't need to pay attention to).  The fix will be in 7.1.0 and 7.0.5, so please test when they are available and re-open if the "text out of frame" problem persists, or the line-breaks are really too ugly.
Comment 7 tiansworld 2021-03-11 09:33:48 UTC
Created attachment 170406 [details]
Translation on the top can't be fully displayed.
Comment 8 tiansworld 2021-03-11 09:40:46 UTC
The issue is not completely resolved in LibreOffice 7.1.1.2.

Please see the detail in the screenshot. The first string in the red rectangle.

Version information:
Version: 7.1.1.2 / LibreOffice Community
Build ID: fe0b08f4af1bacafe4c7ecc87ce55bb426164676
Comment 9 tiansworld 2021-03-11 09:48:48 UTC
(In reply to Ming Hua from comment #6)
> (In reply to tiansworld from comment #5)
> > In my view, I'd like to remove the (换行) too.
> I'd rather keep it as the English text lists "enter" and "return"
> separately, and both terms are used in Chinese as well.
> 

I agree that we use both terms in our language. 

But the later one(return) is used more commonly on the software context, for example when programming, writing some stuffs.
When we talk about the hardware, the keyboard, I am sure almost all of the people only know(say) "enter"(回车键).

And here, it means the keyboard. So "换行" can be removed.
Comment 10 Ming Hua 2021-03-12 09:40:57 UTC
(In reply to tiansworld from comment #8)
> The issue is not completely resolved in LibreOffice 7.1.1.2.
> 
> Please see the detail in the screenshot. The first string in the red
> rectangle.
This is really strange, as the second line for "previous slide or previous effect" wraps (if not at the ideal position), but the first line for "next slide or next effect" doesn't.

I don't have a second monitor so can't test this presenter console feature.  If there is a way for single-monitor setup to test this, let me know.

Regardless, this issue is now out of my expertise area as a translator.  I've changed the summary and other fields as needed, and hopefully another QA person or a developer with more knowledge can take a look.

> Version information:
> Version: 7.1.1.2 / LibreOffice Community
> Build ID: fe0b08f4af1bacafe4c7ecc87ce55bb426164676
Comment 11 tiansworld 2021-03-12 10:38:06 UTC
(In reply to Ming Hua from comment #10)
> (In reply to tiansworld from comment #8)
> > The issue is not completely resolved in LibreOffice 7.1.1.2.
> > 
> > Please see the detail in the screenshot. The first string in the red
> > rectangle.
> This is really strange, as the second line for "previous slide or previous
> effect" wraps (if not at the ideal position), but the first line for "next
> slide or next effect" doesn't.
> 

What about breaking the line into two lines?

> I don't have a second monitor so can't test this presenter console feature. 
> If there is a way for single-monitor setup to test this, let me know.
> 

Neither do I. I test it with a TV mirrored via AirPlay, or connect the HDMI cable.
Since this is not a platform specific issue, you can try to test it on Linux/Windows, with a TV that supports MiraCast. Although I am not sure which Linux distribution supports that, windows 10 is OK.

BTW, could you tell me which file in the L10n LibreOffice installation directory contains this string? And which one is the corresponding one on Weblate? So I can download that file and test it directly once you fix it.

Last time it took me much time on looking for the files, but I couldn't find them.
Comment 12 Ming Hua 2021-03-12 11:45:12 UTC
(In reply to tiansworld from comment #11)
> (In reply to Ming Hua from comment #10)
> > (In reply to tiansworld from comment #8)
> > > The issue is not completely resolved in LibreOffice 7.1.1.2.
> > > 
> > > Please see the detail in the screenshot. The first string in the red
> > > rectangle.
> > This is really strange, as the second line for "previous slide or previous
> > effect" wraps (if not at the ideal position), but the first line for "next
> > slide or next effect" doesn't.
> 
> What about breaking the line into two lines?
I'm not willing to try this without being able to test locally first.  And I have neither a local build environment nor dual-display setup to test it.

> BTW, could you tell me which file in the L10n LibreOffice installation
> directory contains this string? And which one is the corresponding one on
> Weblate? So I can download that file and test it directly once you fix it.
> 
> Last time it took me much time on looking for the files, but I couldn't find
> them.
LibreOffice's l10n framework is rather unique, and as far as I can tell the translated strings for an installed system are in some .xcd file in $INSTALL_DIR/share/registy/, likely one of those three with _zh-CN.xcd suffix.  On Windows the default $INSTALL_DIR is C:\Program Files\LibreOffice\.

These .xcd files are processed binary files, and there are not equivalent files on Weblate.  Weblate just uses LibreOffice's regular .po files in the source code (if you are not familiar with .po files, please search for GNU gettext documentation).  The .po files are converted to .xcd files during the build process, and I don't know the exact details.

Sorry I can't help you much on this.  Please use other resources (Ask LibreOffice website, IRC user/developer channels, for example) if you still seek an answer.
Comment 13 tiansworld 2021-03-12 16:58:52 UTC
(In reply to Ming Hua from comment #12)
> (In reply to tiansworld from comment #11)
> > (In reply to Ming Hua from comment #10)
> > > (In reply to tiansworld from comment #8)
> > > > The issue is not completely resolved in LibreOffice 7.1.1.2.
> > > > 
> > > > Please see the detail in the screenshot. The first string in the red
> > > > rectangle.
> > > This is really strange, as the second line for "previous slide or previous
> > > effect" wraps (if not at the ideal position), but the first line for "next
> > > slide or next effect" doesn't.
> > 

> > BTW, could you tell me which file in the L10n LibreOffice installation
> > directory contains this string? And which one is the corresponding one on
> > Weblate? So I can download that file and test it directly once you fix it.
> > 
> > Last time it took me much time on looking for the files, but I couldn't find
> > them.
Thanks for your tips about xcd files. Previously I spent my time on the mo files.

The file holds the string is /LibreOffice.app/Contents/Resources/registry/res/registry_zh-CN.xcd . The xcd is a xml type file, and can be edited directly in text editing tools.

I solved the problem by adding a space before the word "Page" within that string. After several tests, it seems that any spaces before "Page" and after the first Chinese character "鼠" would solve the problem.

I counted the half-width characters in the first line in English Impress remote control help, the length is 32 before wrapped automatically.

"Left click, right or down arrow,*32nd is here* 
spacebar, page down, enter, return, 'N'".

The tests showed that if the string is very long, then it will be automatically wrapped if there is any space before the 32nd character. The English string has many spaces, so there is no displaying problem. 

However, there is no space before the 32nd character in the translation string: "鼠标左键,右/下箭头、空格、Page Down、回车 (换行)、或 N 键", which is before the in word "Down". So the problem exists.

I guess the central cause is probably the xml style or other backends configurations in LibreOffice.



> > What about breaking the line into two lines?
> I'm not willing to try this without being able to test locally first.  And I
> have neither a local build environment nor dual-display setup to test it.
> 
OK.
I'd like to know if a single space added before "Page" in the po file will work.

If you don't believe my test, then please find someone you trust and let him/her do the test.
I don't think lacking of testing environment would stop you from doing such a simple update to the translation.
Comment 14 Ming Hua 2021-03-13 19:14:08 UTC
(In reply to tiansworld from comment #13)
> The file holds the string is
> /LibreOffice.app/Contents/Resources/registry/res/registry_zh-CN.xcd . The
> xcd is a xml type file, and can be edited directly in text editing tools.
> 
> I solved the problem by adding a space before the word "Page" within that
> string. After several tests, it seems that any spaces before "Page" and
> after the first Chinese character "鼠" would solve the problem.
Thanks for the investigation and testing.  I've now changed the Chinese translations on Weblate to use half-width commas with a space ", " instead of full-width commas "," for these two long strings, which should help the line wrapping quite a bit.

The changes should make into 7.1.2 RC2 (scheduled in two weeks), so please test when that is released.

I assume the suggestion on Weblate adding a line break is also from you.  If my plan of adding spaces doesn't work, we can try your suggestion.

> If you don't believe my test, then please find someone you trust and let
> him/her do the test.
> I don't think lacking of testing environment would stop you from doing such
> a simple update to the translation.
I never said I don't believe your (or anyone else's) test.  I just said I wouldn't try random ideas without testing it myself first.  But since you did the testing, it's not just random ideas anymore, and I'm happy to make changes based on your test result.

BTW the simplified Chinese translation team of LibreOffice is in real need of some new people.  So if you are interested in improving the quality of zh-CN translations, even just some casual work, I'd be very glad to help you setup a Weblate account so that you can contribute regularly.  But if you just want to submit bugs whenever you see them, that's perfectly OK and very welcomed as well.
Comment 15 tiansworld 2021-03-14 05:55:24 UTC
(In reply to Ming Hua from comment #14)
> (In reply to tiansworld from comment #13)
> > The file holds the string is
> > /LibreOffice.app/Contents/Resources/registry/res/registry_zh-CN.xcd . The
> > xcd is a xml type file, and can be edited directly in text editing tools.
> > 
> > I solved the problem by adding a space before the word "Page" within that
> > string. After several tests, it seems that any spaces before "Page" and
> > after the first Chinese character "鼠" would solve the problem.
> Thanks for the investigation and testing.  I've now changed the Chinese
> translations on Weblate to use half-width commas with a space ", " instead
> of full-width commas "," for these two long strings, which should help the
> line wrapping quite a bit.
> 
> The changes should make into 7.1.2 RC2 (scheduled in two weeks), so please
> test when that is released.

From the test result by changing the xml file directly. A single space just works fine. Let's see if this will work in the po file.

> 
> I assume the suggestion on Weblate adding a line break is also from you.  If
> my plan of adding spaces doesn't work, we can try your suggestion.

Yes, that was me. But that suggestion wasn't made based on my later test of the xml file, rather, it's my experience(I first thought LibreOffice uses mo files directly). I should've changed that suggestion to a space. But it was too late to do it that night.


> 
> > If you don't believe my test, then please find someone you trust and let
> > him/her do the test.
> > I don't think lacking of testing environment would stop you from doing such
> > a simple update to the translation.
> I never said I don't believe your (or anyone else's) test.  I just said I
> wouldn't try random ideas without testing it myself first.  But since you
> did the testing, it's not just random ideas anymore, and I'm happy to make
> changes based on your test result.
> 

That's OK.

> BTW the simplified Chinese translation team of LibreOffice is in real need
> of some new people.  So if you are interested in improving the quality of
> zh-CN translations, even just some casual work, I'd be very glad to help you
> setup a Weblate account so that you can contribute regularly.  But if you
> just want to submit bugs whenever you see them, that's perfectly OK and very
> welcomed as well.

Thanks for your kindness.
I won't consider doing it in the near future. Based on my current using experience of the zh_CN GUI, I haven't found any low quality strings. You are doing it very well.
Comment 16 Ming Hua 2021-03-29 00:29:19 UTC
(In reply to Ming Hua from comment #14)
> The changes should make into 7.1.2 RC2 (scheduled in two weeks), so please
> test when that is released.
Correction: I didn't realize that this particular string has diverged between 7-1 and master branch.  So the changes I made for master won't affect 7.1.x releases.

I've now also changed the string for 7-1 branch, but of course it's a bit late for 7.1.2.  So please either test 7.1.3 (RC1 should be in two or three weeks) releases or test a 7.2 daily build.
Comment 17 tiansworld 2021-05-19 09:22:35 UTC
Created attachment 172169 [details]
Fixed
Comment 18 tiansworld 2021-05-19 09:24:38 UTC
Comment on attachment 172169 [details]
Fixed

It's fixed in Version: 7.1.3.2 / LibreOffice Community.
Build ID: 47f78053abe362b9384784d31a6e56f8511eb1c1

Thanks a lot.
Comment 19 tiansworld 2021-05-19 09:52:53 UTC
Created attachment 172170 [details]
zh_TW has the problem also

Traditional Chinese UI has the same problem.
Comment 20 tiansworld 2021-05-19 09:53:48 UTC
zh_TW Translation needs to be fixed too.
Comment 21 Cheng-Chia Tseng 2021-06-08 08:05:14 UTC
Thanks, Tian.

Although it is a bug of LibreOffice text processing, I also made the corresponding changes (like adding space after "、" mark) for workarounds for zh_TW (traditional Chinese).