Bug 142724 - In "Asian Phonetic Guide" dialog, Options in "Position" drop-down menu are mislabeled.
Summary: In "Asian Phonetic Guide" dialog, Options in "Position" drop-down menu are mi...
Status: NEW
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: UI (show other bugs)
Version:
(earliest affected)
unspecified
Hardware: All All
: medium enhancement
Assignee: Not Assigned
URL:
Whiteboard:
Keywords:
Depends on:
Blocks: Ruby
  Show dependency treegraph
 
Reported: 2021-06-09 02:26 UTC by Petro Ding
Modified: 2021-06-14 08:23 UTC (History)
4 users (show)

See Also:
Crash report or crash signature:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Petro Ding 2021-06-09 02:26:56 UTC
Description:
The first two choices in the "Position" drop-down menu are mislabeled as "top" and "bottom". Such labeling are true for horizontal text but not for vertical text. For vertical text, the "top" option would put ruby text on the right of the base text, and the "bottom" option would put ruby text on the left of the base text. These two options should be labeled "top/right" and "bottom/left".

Steps to Reproduce:
1. Set the page's text direction to "Right-to-left (vertical)"; to do this, select "Format > Page Style > Page > Paper Format > Text Direction > Right-to-left (vertical)".
2. Select "Format > Asian Phonetic Guide".
3. Type any Chinese Character (e.g. 人) in "Base text", then any text in "Ruby text".
4. Select "Top" in "Position" drop-down menu, then click "Apply" button.
5. Don't close the dialog, Select "Bottom" in "Position" drop-down menu, then click "Apply" button.

Actual Results:
After step #4, a new ruby text showed up at the right of a new vertical base text, which is expected. The command is however labeled as "top", which is not expected.

After step #5, a new ruby text showed up at the left of a new vertical base text, which is expected. The command is however labeled as "bottom", which is not expected.

Expected Results:
The first command in the "Position" drop-down menu should be labeled as "top/right" rather than "top".
The second command in the "Position" drop-down menu should be labeled as "bottom/left" rather than "bottom".


Reproducible: Always


User Profile Reset: No



Additional Info:
None.
Comment 1 Heiko Tietze 2021-06-11 08:35:38 UTC
I think this needs to be solved in the translation. Cannot think of a generic terminology like odd/even instead of left/right pages regarding LTR vs RTL.
Comment 2 Ming Hua 2021-06-11 09:11:07 UTC
(In reply to Heiko Tietze from comment #1)
> I think this needs to be solved in the translation. Cannot think of a
> generic terminology like odd/even instead of left/right pages regarding LTR
> vs RTL.
It has nothing to do with RTL.

(In reply to Petro Ding from comment #0)
> 1. Set the page's text direction to "Right-to-left (vertical)"; to do this,
> select "Format > Page Style > Page > Paper Format > Text Direction >
> Right-to-left (vertical)".
The text direction relevant here is "Right-to-left (vertical)", which means text flows vertically, from top to bottom, then the rows (text lines? columns?) are arranged from right to left.  (The terminology is indeed confusing, which probably should be another bug.)

This is the traditional text direction for Chinese and Japanese.  There are also scripts that write vertically, but lines are arranged from left to right, such as traditional Mongolian (also called Hudum script).

So here the problem is that Chinese/Japanese text can be horizontal or vertical, and there are plenty of UI parts that are aware of this difference and change accordingly (indent icons on toolbar, for example), but the Asian Phonetic Guide dialog simply doesn't, and always assume horizontal text direction.

To reiterate, this is not the left/right difference that RTL languages usually have with UI, but horizontal/vertical difference (likely) specific to CJK.  And both directions are used in the same language, therefore the problem exists for English UI as well.
Comment 3 Heiko Tietze 2021-06-11 09:47:03 UTC
Sure, RTL/LTR was just an example where we could find a "compromise" with odd/even instead of left/right. I cannot think of such solution for top/bottom other than translating "left" in terms of "top". That's why I set NOB, but feel free to reopen with a suggestion.
Comment 4 Ming Hua 2021-06-11 10:17:29 UTC
(In reply to Heiko Tietze from comment #3)
> Sure, RTL/LTR was just an example where we could find a "compromise" with
> odd/even instead of left/right. I cannot think of such solution for
> top/bottom other than translating "left" in terms of "top". That's why I set
> NOB, but feel free to reopen with a suggestion.
I see.  But if you understood the problem properly, why would you dismiss the simple "top" => "top/right" and "bottom" => "bottom/left" suggestion by the reporter?  Sounds a reasonable, if non-elegant, compromise to me.

A more elegant solution would be making the labels context aware, and having them changing from "top" to "right" when in vertical layout, just like the toolbar icons do.  But that would be a lot more work.  I would perfectly understand a WONTFIX status, but disagree with NOTABUG/NOTOURBUG.
Comment 5 Heiko Tietze 2021-06-11 11:38:18 UTC
(In reply to Ming Hua from comment #4)
> ...but disagree with NOTABUG/NOTOURBUG.
The idea was to have the conditional formatting with the translation. Drawback here is that using different UI and document languages is not a far-fetched use case. 

The unelegant solution of left/top is very confusing to ordinary, non-asian users. I'd do it via code.
Comment 6 V Stuart Foote 2021-06-11 14:01:29 UTC
OK, but conext sensitivity/translation would have to be encoded per locale--not just the Western / CJK / CTL mode of the language. See also bug 98211 worked through similar for the Paragraph 'Last line' handling.  Language neutral labeling vs. overhead of doing language sensitive context for paragraph text layout modes LRTB, RLTB, TBRL, TBLR would be great--and of course we can't support the BTLR of the few SouthEast Asian scripts that support it.

Absent that, the inelegant "top/right" and "bottom/left" would be perfectly acceptable to hard code for this dialog.

As a reminder for those interested there was Frank Oberle's treatise on our issues with handling script and locales-- see attachements to bug 92655
Comment 7 sophie 2021-06-14 08:17:01 UTC
(In reply to Ming Hua from comment #4)
> (In reply to Heiko Tietze from comment #3)
> > Sure, RTL/LTR was just an example where we could find a "compromise" with
> > odd/even instead of left/right. I cannot think of such solution for
> > top/bottom other than translating "left" in terms of "top". That's why I set
> > NOB, but feel free to reopen with a suggestion.
> I see.  But if you understood the problem properly, why would you dismiss
> the simple "top" => "top/right" and "bottom" => "bottom/left" suggestion by
> the reporter?  Sounds a reasonable, if non-elegant, compromise to me.

I agree with Ming here, this is a reasonable and less confusing solution than having labels in the UI not reflecting what they should do.
Comment 8 Heiko Tietze 2021-06-14 08:23:37 UTC
So let's introduce STR* variables and fill the menus dynamically. We could change the default to "Left/Top" to draw attention on this modification, though this means more work for the translators.