When in the new sidebar the Navigator is selected and its pane is shown, it contains English strings (Headings, Tables, Text frames ...) and not the localized ones. AFAIK Slovenian had a 100 % localized strings for LO41b2 and yet it shows in LO41b2, so this probably means one of two things: - these strings landed one day before the beta2 checkout and could not be localized in time - or - - these strings are not yet localizable (but should be). Its tooltips are also in English, e.g. "0 Headings"... Also, and should report this in another bug report, the "longer than English strings" get cut and are not shown fully in the sidebar subwindows.
Hi there :-), (In reply to comment #0) > When in the new sidebar the Navigator is selected and its pane is shown, it > contains English strings (Headings, Tables, Text frames ...) and not the > localized ones. > AFAIK Slovenian had a 100 % localized strings for LO41b2 and yet it shows in > LO41b2, so this probably means one of two things: Mmh, following Pootle there are still 972 unlocalized UI words and 169255 unlocalized Help words. See: https://translations.documentfoundation.org/sk/ Most probably these strings are not translated yet. I think all Slovenian users would thank you if you can help the team translating them (if you don't do that already of course :-) ). If all these UI strings are translated, and the sidebar (and the other parts of LibreOffice you report a bug to) is still no in your localized language, please reopen this bug :-). But I think for now it is better to mark it as 'RESOLVED NOTABUG'. Kind regards, Joren PS: if you aren't subscribed to your local mailinglist: http://sk.libreoffice.org/index.php/komunita-pouzivate-ov-libreoffice/ :-) great opportunity to help others and ask questions to others (if you aren't already subscribed ;-) ).
*** Bug 65484 has been marked as a duplicate of this bug. ***
*** Bug 65485 has been marked as a duplicate of this bug. ***
Joren, I am the lead SL localizer and 41b2 was 100% localized on Sunday 3pm CET. The beta2 was pulled on Monday. Either these strings are unlocalizable or a large pile of UI strings for sidebar landed since Sunday 3pm till Monday 2pm CET. Don't close if you don't know what the bug is about!
BTW Slovenian is not using Pootle, we use our own translation system and Andras Timer is pushing our translations in. So there is no way for you to know from Pootle what % Slovenian is at.
Okay, I made a horrible translation error myself here :-). Slovenian is _indeed_ mostly translated see https://translations.documentfoundation.org/sl/ instead of the other link I posted :-). I'm sorry about that. @Timar: it looks to me that the Slovenian UI can't be translated using Pootle etc. Is that correct? @bug reporter: if Timar can open the unlocalized strings. Are you willing to help it translate, because I think this isn't 'opened' yet due the fact none offered to translate it yet? Kind regards, Joren
(In reply to comment #5) > BTW Slovenian is not using Pootle, we use our own translation system and > Andras Timer is pushing our translations in. So there is no way for you to > know from Pootle what % Slovenian is at. Another thing I didn't know. Then is Timar our only expert here :-). PS: @Timar: just for my info, why is that :-)?
I can answer - because we choose not to use Pootle because of a faster turnaround and because we have our own translation system. And that is not the subject of this bug. So do not change the subject nor the focus, please! I opened this bug to make developers aware that there are strings in b2 that seem: - either unlocalizable (which is a bug and they must become localizable for all) - or they landed in the last 24 hours before b2 pullout (which is not a bug itself and they will be available for translation on the road to RC1). So please do not mess with this bug until we get it clear which is the right answer. Other languages have these strings unlocalized as well. Pootle was not updated in the last 24 hours before beta2 pullout.
This looks like an l10ntools problem, translations of this particular file are not merged to .res files when the language code is after 'qtz' in the alphabet.
Zolnai Tamas committed a patch related to this issue. It has been pushed to "master": http://cgit.freedesktop.org/libreoffice/core/commit/?id=58a9d35b84947510f78e3ffeb6d1ef9a9adac0cb fdo#65483 Invalid po lines caused missing translations 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.
Zolnai Tamas committed a patch related to this issue. It has been pushed to "libreoffice-4-1": http://cgit.freedesktop.org/libreoffice/core/commit/?id=1f91be7dddafa67cd2985e1528e1cb1951bf8edf&h=libreoffice-4-1 fdo#65483 Invalid po lines caused missing translations It will be available in LibreOffice 4.1. 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.
Some background info: I usually run a script on .po files that shapes and validates them. This includes removing of obsolete entries (linbes starting with #~). Somehow I forgot to run this on sr and sh files and l10ntools could not handle the situation. Tamas' fix limited the scope of the bug. My fix removed the faulty lines, so the bug does not occur on current files. It would be good, however, if our po class could handle obsolete entries, i.e. skip them.