Bug Hunting Session
Bug 113777 - Problems with labels/strings in Character dialog's font tab
Summary: Problems with labels/strings in Character dialog's font tab
Status: RESOLVED FIXED
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Writer (show other bugs)
Version:
(earliest affected)
6.0.0.0.alpha1+
Hardware: All All
: medium normal
Assignee: Not Assigned
URL:
Whiteboard: target:6.0.0
Keywords:
Depends on:
Blocks: Character-Dialog l10n-Optimization
  Show dependency treegraph
 
Reported: 2017-11-12 03:38 UTC by Yousuf Philips (jay) (retired)
Modified: 2017-12-13 23:58 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 Yousuf Philips (jay) (retired) 2017-11-12 03:38:20 UTC
The .ui file of the font tab[1] of the character dialog has 4 duplicate labels of 'Family:', 'Style:', 'Size:', and 'Language:' and all of them are set as translatable, which is unnecessary translation work. We also have in the code that 'Family:' and 'Style:' be replaced with 'Font' on Windows and 'Typeface' and Mac[2], but on Linux it is being replaced by 'Family' and 'Style' without colons[3].

I think we need to

1. Add the colon to 'Family', 'Style', 'Font' and 'Typeface' in the code, ideally without requiring translators to retranslate them
2. Add 'Size:' and 'Language:' as strings in the code that replace the labels at runtime
3. Turn the translate flag off of these 16 labels in the .ui file


[1] https://opengrok.libreoffice.org/xref/core/cui/uiconfig/ui/charnamepage.ui

[2] https://opengrok.libreoffice.org/xref/core/cui/source/tabpages/chardlg.cxx#315

[3] https://opengrok.libreoffice.org/xref/core/cui/inc/strings.hrc#323
Comment 1 Heiko Tietze 2017-11-12 09:55:49 UTC
Captions do not have an ending colon usually. The question is if we want to get rid of it at all places or keep it wrong but consistent.

The issue about terminology goes to the l10n team. Sophie, please set to NEW if you think we
Comment 2 Adolfo Jayme 2017-11-12 19:00:18 UTC
Heiko, please take into account that we’ve added colons to hundreds of labels on the basis that they were recommended in the GNOME 2.x guidelines in bug 78826. L10n bushed back vigorously against mass-changing strings, and to this day we can’t make the consistent without affecting millions of translations (Mozilla’s tools, on the contrary, allow for these changes).
Comment 3 Heiko Tietze 2017-11-15 10:45:08 UTC
Adolfo is right, colons are necessary. Esp. the ally thing is a relevant aspect.

Gnome HIG: 
"If the label precedes the control it is labelling, end the label with a colon."
(https://developer.gnome.org/hig-book/unstable/design-text-labels.html.en)

MSDN:
"Use after labels for drop-down, list, text, and spin boxes; sliders; and text areas. Place a colon after labels for check boxes or option buttons only if they precede another control. Use a colon to introduce a list of items."
(https://msdn.microsoft.com/en-us/library/windows/desktop/bb226801(v=vs.85).aspx)

"Use colons at the end of external control labels. This is particularly important for accessibility because some assistive technologies look for colons to identify control labels."
(https://msdn.microsoft.com/en-us/library/windows/desktop/dn742478(v=vs.85).aspx)

macOS:
"Use a colon when introducing a control. A colon implies a direct connection between the label text and a particular control or set of controls. A colon becomes unnecessary when the label and control work together to form a single sentence." (Example without colon: "Enter text here [      ]")
(https://developer.apple.com/macos/human-interface-guidelines/fields-and-labels/labels/)
Comment 4 Yousuf Philips (jay) (retired) 2017-11-15 13:03:19 UTC
Patch is in for turning off translation flag for 'Family:' and 'Style:'
https://gerrit.libreoffice.org/44761
Comment 5 Yousuf Philips (jay) (retired) 2017-11-15 16:42:00 UTC
Caolan mentioned on irc that a quick fix for the ':' issue in chardlg.cxx would be to '... try sFontFamilyString += ":"', so here is the patch for it, if we want to go with this approach.

https://gerrit.libreoffice.org/44768
Comment 6 Yousuf Philips (jay) (retired) 2017-11-18 11:07:48 UTC
(In reply to Yousuf Philips (jay) from comment #5)
> https://gerrit.libreoffice.org/44768

Gabor said on gerrit "Please don't do this. Such code level string surgery almost always breaks in *some* language. Also, with this you assume that a colon is what *every* language wants as separator here, RTL and non-latin ones included.
Please change the translatable strings. Even if some translators throw a tantrum."

So here is the new patch
https://gerrit.libreoffice.org/44905
Comment 7 Commit Notification 2017-11-18 16:16:22 UTC
Yousuf Philips committed a patch related to this issue.
It has been pushed to "master":

http://cgit.freedesktop.org/libreoffice/core/commit/?id=49098daf5795499f6c34298d9476ab42125de51a

tdf#113777 Add colon after family and style labels

It will be available in 6.0.0.

The patch should be included in the daily builds available at
http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More
information about daily builds can be found at:
http://wiki.documentfoundation.org/Testing_Daily_Builds

Affected users are encouraged to test the fix and report feedback.
Comment 8 Commit Notification 2017-11-19 10:46:03 UTC
Yousuf Philips committed a patch related to this issue.
It has been pushed to "master":

http://cgit.freedesktop.org/libreoffice/core/commit/?id=cba0399132bb1d10054b9ade0c035dc49d8d3d2f

tdf#113777 dont translate 'Family:' and 'Style:' strings

It will be available in 6.0.0.

The patch should be included in the daily builds available at
http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More
information about daily builds can be found at:
http://wiki.documentfoundation.org/Testing_Daily_Builds

Affected users are encouraged to test the fix and report feedback.