Created attachment 121246 [details] word completion tab with unlocalized drop-down for cs In Tools - AutoCorrect - AutoCorrent Options - Word Completion tab, there is the "Accept with" drop-down with English key names (End, Return, Space, Right, Tab) which cannot be localized (the names are not in .po files for translation). Also, the "Return" should be renamed to "Enter" (it seems that "Enter" appears on Windows whereas "Return" on Linux). Checked in 5.1 beta 2 (Ubuntu), cs locale, presumably inherited from OOo (observed also in 3.5.4 and AOO 4.1.2).
Code pointer: http://opengrok.libreoffice.org/xref/core/officecfg/registry/schema/org/openoffice/Office/Writer.xcs#4649
Hi, I tested under Win8.1 x64 and it's correctly localized (at least in the italian version) using LibO 5.0.3.1 Build ID: fd8cfc22f7f58033351fcb8a83b92acbadb0749e Versione locale: it-IT (it_IT) so I suspect the issue is just in the CS locale. @Julien and Sophie what about the french locale? who's the CS locale team leader to ping?
Interesting, but these strings have no KeyID (qtz locale) so they can't be found in .po files - or are they there for Italian translation? I am Czech localizer - so I could fix this easily if the strings were translatable.
@Valter Mura can you answer Stanislav's question?
(In reply to tommy27 from comment #2) [...] > what about the french locale? No problem in French localization for 5.0 and 5.1. In 4.4 there is only one item of the dropdown list which is not localized (Space). In Pootle, for the master, the string is "Acc_ept with:", it is there: Comment: W8dF5 libo_ui/cui/uiconfig/ui.po Unit #79289479 wordcompletionpage.ui label3 label string.text wordcompletionpage.ui Best regards. JBF
It seems that Pootle contains the same strings for both French and Czech: there is "Accept with" (which is localized in cs), but the key names ("End", "Return" etc.) are missing. So I think the translation for French and Italian has been done somehow out of Pootle which is what confuses me...
(In reply to Stanislav Horacek from comment #6) > It seems that Pootle contains the same strings for both French and Czech: > there is "Accept with" (which is localized in cs), but the key names ("End", > "Return" etc.) are missing. > > So I think the translation for French and Italian has been done somehow out > of Pootle which is what confuses me... I am not sure but I believe that translations of words like End, Return, Space (for spacebar) are taken from the OS. Best regards. JBF
(In reply to Jean-Baptiste Faure from comment #7) > (In reply to Stanislav Horacek from comment #6) > > It seems that Pootle contains the same strings for both French and Czech: > > there is "Accept with" (which is localized in cs), but the key names ("End", > > "Return" etc.) are missing. > > > > So I think the translation for French and Italian has been done somehow out > > of Pootle which is what confuses me... > > I am not sure but I believe that translations of words like End, Return, > Space (for spacebar) are taken from the OS. > Jean Baptiste, maybe you're right. However, there are other parts which I cannot translate, or better I cannot find; these are the comments (text field 'Description') to the commands in Tools/Customize. Please check and confirm if I'm right.
(In reply to Valter Mura from comment #8) > [...] > However, there are other parts which I cannot translate, or better I cannot > find; these are the comments (text field 'Description') to the commands in > Tools/Customize. Please check and confirm if I'm right. Indeed, the string from Tools > Customize > Menus -> menu Edition, entry Fields, "Opens a dialog where you can edit the properties of a field. Click in front of a field, and then choose this command." is not translated in French and I can't find it in Pootle: there is 51 occurrences of "where" in the UI and none of them match this string. There is other strings not translated / translatable : Entry: Change Database -> "Change the data sources for the current document." Only 3 strings with the word "sources". In the menu Edition | Reference : all 3 menus entry descriptions etc. Best regards. JBF
No, these strings in customization *are* translatable - though they're not part of UI, but Help (the texts enclosed by <ahelp> tags). For instance, the Fields description is available here (and I am pretty sure that the others can be found there too): https://translations.documentfoundation.org/cs/libo_help/translate/swriter/01.po#unit=100754052 In any case, other bugs should be filed separately - this one is about the word completion drop-down (and you probably did not want to confirm it). As we agreed that its translation is not handled by LibreOffice, I would suggest to change this to allow its translation in Pootle.
Key names are handled differently in each VCL plugin. Some examples: gtk2: It's possible to translate these strings in vcl/unx/generic/app/keysymnames.cxx. Strings that are missing there, are taken from Xlib using XKeysymToString. gtk3: We get names from gtk using gtk_accelerator_get_label.
(In reply to Stanislav Horacek from comment #10) > No, these strings in customization *are* translatable - though they're not > part of UI, but Help (the texts enclosed by <ahelp> tags). > > For instance, the Fields description is available here (and I am pretty sure > that the others can be found there too): > https://translations.documentfoundation.org/cs/libo_help/translate/swriter/ > 01.po#unit=100754052 > > In any case, other bugs should be filed separately - this one is about the > word completion drop-down (and you probably did not want to confirm it). As > we agreed that its translation is not handled by LibreOffice, I would > suggest to change this to allow its translation in Pootle. In this case, all Italian strings are translated. So, the problem is that the <ahelp hid="." visibility="hidden"> status doesn't allow to correct show the translated tip. Many of them are contextualized (example: <ahelp hid="HID_SCRL_PAGEUP">), many others not. Is it correct?
** Please read this message in its entirety before responding ** To make sure we're focusing on the bugs that affect our users today, LibreOffice QA is asking bug reporters and confirmers to retest open, confirmed bugs which have not been touched for over a year. There have been thousands of bug fixes and commits since anyone checked on this bug report. During that time, it's possible that the bug has been fixed, or the details of the problem have changed. We'd really appreciate your help in getting confirmation that the bug is still present. If you have time, please do the following: Test to see if the bug is still present on a currently supported version of LibreOffice (5.4.1 or 5.3.6 https://www.libreoffice.org/download/ If the bug is present, please leave a comment that includes the version of LibreOffice and your operating system, and any changes you see in the bug behavior If the bug is NOT present, please set the bug's Status field to RESOLVED-WORKSFORME and leave a short comment that includes your version of LibreOffice and Operating System Please DO NOT Update the version field Reply via email (please reply directly on the bug tracker) Set the bug's Status field to RESOLVED - FIXED (this status has a particular meaning that is not appropriate in this case) If you want to do more to help you can test to see if your issue is a REGRESSION. To do so: 1. Download and install oldest version of LibreOffice (usually 3.3 unless your bug pertains to a feature added after 3.3) http://downloadarchive.documentfoundation.org/libreoffice/old/ 2. Test your bug 3. Leave a comment with your results. 4a. If the bug was present with 3.3 - set version to "inherited from OOo"; 4b. If the bug was not present in 3.3 - add "regression" to keyword Feel free to come ask questions or to say hello in our QA chat: http://webchat.freenode.net/?channels=libreoffice-qa Thank you for helping us make LibreOffice even better for everyone! Warm Regards, QA Team MassPing-UntouchedBug-20170901
With Czech UI + LO master sources updated today, I got: End Enter Mezerník Vpravo Tabulátor
I can confirm this - I guess that this is because gtk3 plugin is now enabled and it takes translations from GTK: https://gitlab.gnome.org/GNOME/gtk/blob/master/po/cs.po
(In reply to Stanislav Horacek from comment #15) > I can confirm this - I guess that this is because gtk3 plugin is now enabled > and it takes translations from GTK: > https://gitlab.gnome.org/GNOME/gtk/blob/master/po/cs.po So is it ok for you or "End" and "Enter" should be also translated? But even if it's the case, since it depends on GTK, it's not related to LO. In brief, we'd put either WFM or NOTOURBUG, shouldn't we?
Yes, the GTK3 translation is OK ("End" and "Enter" are correct in Czech translation). I'm not sure about the other plugins (for KDE4 I get not localized strings) - but it is apparently matter of upstream and I agree with closing of this bug.
Thank you for your feedback. Let's put this one to WFM then since the fix has been done outside LO.