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
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
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).
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/)
Patch is in for turning off translation flag for 'Family:' and 'Style:' https://gerrit.libreoffice.org/44761
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
(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
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.
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.