Apache OpenOffice (AOO) Bugzilla – Full Text Issue Listing |
Summary: | Errors in the OpenOffice.org 2.3 Help strings | ||
---|---|---|---|
Product: | documentation | Reporter: | clytie |
Component: | Online help | Assignee: | Uwe Fischer <uwefis> |
Status: | CLOSED NOT_AN_OOO_ISSUE | QA Contact: | issues@documentation <issues> |
Severity: | Trivial | ||
Priority: | P3 | CC: | issues |
Version: | current | ||
Target Milestone: | --- | ||
Hardware: | All | ||
OS: | All | ||
Issue Type: | DEFECT | Latest Confirmation in: | --- |
Developer Difficulty: | --- |
Description
clytie
2007-07-26 05:04:29 UTC
Thank you for your comments. Looks most of them regard UI strings. Please submit those comments to the appropriate Component and Subcomponent. For example send Writer strings to Component "Word processor", most possible with Subcomponent = "UI" or such (cannot look this up now). Send Calc strings to "Spreadsheet", send strings that appear in multiple contexts to "framework". Thank you for the pointer to "gettext plurals" - http://www.gnu.org/software/gettext/manual/gettext.html#Plural-forms is a very interesting information in the gettext manual. So let's look at the strings from application help: (g) \\<ahelp hid=\\\".uno:TestMode\\\"\\>Starts test mode. Use the dialog closer to return to design mode.\\</ahelp\\> changed this as suggested in file sbasic/shared/02/20000000.xhp Tools bar: Yes, OOo has a toolbar called "Tools". Translate it different if this is a problem. For example in German, AFAIK "Tools" is the "Werkzeugleiste", while "toolbars" are "Symbolleisten". All of our Mac keyboards have different Backspace and Delete keys. It may be possible that the label on both is the same, which would be a Mac issue. (I've heard that most older US Mac keyboards have this bug) Enter - in a selected range This string is part of a table. As such it must be as short as possible so that the table does not get distorted. Replaced it by "Enter (in a selected range)" in file scalc/04/01020000.xhp The whole localization process seems to be broken if translators cannot see the context of the strings. Consistency of strings in the application help is one of our targets for the next version. We are working on templates and style guide directions - see the dev@documentation.openoffice.org mail list. Missing "a" and "the" determiners should be re-inserted, according to Sun Style Guide. Unfortunately, someone took his time to remove many of those in the last years. object-->objects: changed sdraw/04/01020000.xhp source\text\sdraw\guide\align_arrange.xhp: I will not change the "name" attribute because this may be used as a link target from other files and I can image a comma inside will lead to trouble later. No user ever sees this attribute. Changed the other strings as suggested. source\text\sdraw\guide\combine_etc.xhp: changed alt text for illustration. 18030000.xhp#par_id3147403.2.help.text Hidden help text is displayed in that yellow Extended Help texts only. The text is not visible on the help page in Help Viewer. There is an issue with links inside Extended Help text, which possibly might never get fixed, so I must duplicate the text, where the text without a link is used as a hidden help text and the text with the helpful link is used as a normal visible text. SEL and HYP strings - don't worry to translate them now, they got removed in version m220 or m221. Thos - hyphen or minus sign - strings were marked with the attribute l10n="K" which meant "do not translate". Those paragraphs should have been set automatically to use the attribute localize=false, but somehow this failed. I deleted the five paragraphs you quoted. <embedvar href=\"text/shared/02/09070000.xhp#hyperdia\"/\> 08090000.xhp#par_idN1062F.help.text you do not have to translate this, there is no translatable text. I cannot find this in the current CWS hcshared10, so it might have been deleted. All BASIC code examples are translatable. Use your own distinction to translate variable names, remarks, strings inside quotes, etc. Do not translate the built-in function names except when they got translated in UI, too (but that should not be the case for BASIC. Calc functions however are translated in some languages.) Thank you for your extensive error report. Thanks for the reminder: I'll try to find time to report the UI errors against the different components. I spent the last few days working on the Help, so I forgot the earlier errors weren't from Help. About the Mac keyboards: ___ All of our Mac keyboards have different Backspace and Delete keys. It may be possible that the label on both is the same, which would be a Mac issue. (I've heard that most older US Mac keyboards have this bug) ___ My current MacBook and the G4 and G3 iBooks I had before that all had only a Delete key, which you also use as Backspace. Backspace is not marked. So it does apply to current Mac laptops. I can't use a desktop, being stuck in bed ;) , so I have a laptop POV. About versions: the examples I quoted were from m221. I updated from that milestone before completing the translations and submitting them. The m222 POT files weren't available on the server at that time. About code samples: ___ All BASIC code examples are translatable. Use your own distinction to translate variable names, remarks, strings inside quotes, etc. Do not translate the built-in function names except when they got translated in UI, too (but that should not be the case for BASIC. Calc functions however are translated in some languages.) ___ This looks like a risky translation situation. It would help a lot if translators had some information on what was translatable, and what was not. Even the small subset of linguists who are technically-minded and thus participate in i18n, won't necessarily be familiar with BASIC. (One of my major aims is to remove as many barriers from i18n participation as possible, so the very large subset of linguists who are not technically minded can join our effort. :) ) closed |