[ANN] LibreOffice 3.5.4 RC1 available

l10n
#1

Dear Community,

The Document Foundation is happy to announce the first release
candidate of LibreOffice 3.5.4. The upcoming 3.5.4 will be the fourth
in a series of frequent bugfix releases on our feature-packed 3.5 code
line. Please be aware that LibreOffice 3.5.4 RC1 is not ready for
production use, you should continue to use LibreOffice 3.5.3 for that.

The release is available for Windows, Linux and Mac OS X from our QA
builds download page at

  http://www.libreoffice.org/download/pre-releases/

A note for Windows users: this Release Candidate will uninstall your
current stable build and replace it. If you do not wish this to happen
but still would like to test, you should follow the instructions for
installing in parallel:

http://wiki.documentfoundation.org/Installing_in_parallel

Should you find bugs, please report them to the FreeDesktop Bugzilla:

  https://bugs.freedesktop.org

A good way to assess the RC1 quality is to run some specific manual
tests on it, our TCM wiki page has more details:

http://wiki.documentfoundation.org/QA/Testing/Regression_Tests#Full_Regression_Test

(and the announcement mail: http://lists.freedesktop.org/archives/libreoffice/2011-December/022464.html)

For other ways to get involved with this exciting project - you can
e.g. contribute code:

  https://www.libreoffice.org/get-involved/developers/

translate LibreOffice to your language:

  http://wiki.documentfoundation.org/Translation_for_3.5

or help with funding our operations:

  http://challenge.documentfoundation.org/

A list of known issues with 3.5.4 RC1 is available from our wiki:

  http://wiki.documentfoundation.org/Releases/3.5.4/RC1

Please find the list of changes against LibreOffice 3.5.3 here:

  http://download.documentfoundation.org/libreoffice/src/bugfixes-libreoffice-3-5-4-release-3.5.4.1.log

Let us close again with a BIG Thank You! to all of you having
contributed to the LibreOffice project - this release would not have
been possible without your help.

Yours,

The Document Foundation Board of Directors

#2

Hi,

I don't know anybody else experienced the same issue: if I click on a menu in the main toolbar, I get a different indication for the shortcut vs. the previous one - that's to say, now I see, e.g., for the Italian localization "File|Salva con nome... (Save as...):
- now: "Control+Shift+S" ; before: "Ctrl+Maiusc+S"

So, it seems the interface "doesn't seem to see" the language translation for shortcuts.

Ciao

#3

Hi Valter,

Valter Mura wrote (22-05-12 21:46)

I don't know anybody else experienced the same issue: if I click on a
menu in the main toolbar, I get a different indication for the shortcut
vs. the previous one - that's to say, now I see, e.g., for the Italian
localization "File|Salva con nome... (Save as...):
- now: "Control+Shift+S" ; before: "Ctrl+Maiusc+S"

So, it seems the interface "doesn't seem to see" the language
translation for shortcuts.

I see a sort of the same effect in Dutch.
In 353 : Ctrl+Shft+S
In 354rc1 : Control+Shift+S

Does not look good.

#4

Cor Nouws píše v Út 22. 05. 2012 v 22:42 +0200:

Hi Valter,

Valter Mura wrote (22-05-12 21:46)

> I don't know anybody else experienced the same issue: if I click on a
> menu in the main toolbar, I get a different indication for the shortcut
> vs. the previous one - that's to say, now I see, e.g., for the Italian
> localization "File|Salva con nome... (Save as...):
> - now: "Control+Shift+S" ; before: "Ctrl+Maiusc+S"
>
> So, it seems the interface "doesn't seem to see" the language
> translation for shortcuts.

I see a sort of the same effect in Dutch.
In 353 : Ctrl+Shft+S
In 354rc1 : Control+Shift+S

We did some investigation with Andras. The problem seems to be Linux
specific. The problem is "only" with translation of the special keys,
e.g. "Ctrl", "Alt". The menu describes the right letters. For example,
"Ctrl+A" is used to open new file in Spanish and it shows "Cotrol+A" in
the Spanish "File/Open" menu. The shortcuts work as expected. I am not
happy with the bug but it should not block the release.

Andras found that the regression is most likely caused by the fix:
"lp#818761: Remove SalDisplay::GetKeyboardName", see
http://cgit.freedesktop.org/libreoffice/core/commit/vcl?h=libreoffice-3-5-4&id=8d9e2d9a211f710e91ac7c607fea25895282d245

Thomas, Bjoern, could you please have a look and provide better solution
for 3.5.5 and 3.6.0 releases?

Best Regards,
Petr

#5

Hi Arnold,

thanks a lot for looking at the problem. Unfortunately, the problem is
still there on Linux, see
https://bugs.freedesktop.org/attachment.cgi?id=62153

Thomas Arnhold píše v Ne 27. 05. 2012 v 14:54 +0200:

Hi,

I checked these changes against en_US and de_DE as I commited the changes.

Here's the second change which has to do with Petr's mentioned one:

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

This one is not in LibreOffice 3.5, so it is not related to the
regression. :slight_smile:

I tested 3.5.4rc4 on Windows with de_DE (libo and Windows): File -> Save
as is displayed as Strg+Umschalt+S.

Ah, you did the testing on Windows.

So the removal of those in-code translations make the hole package more
consistent with all other locales.

Makes sense. It seems that the fix
http://cgit.freedesktop.org/libreoffice/core/commit/?id=2233aa52da14ec85331aee1163b885fe9a9fb507 was safe and did not break Windows.

I am afraid that the problem is with the first fix
http://cgit.freedesktop.org/libreoffice/core/commit/vcl?h=libreoffice-3-5-4&id=8d9e2d9a211f710e91ac7c607fea25895282d245
I guess that it broke the stuff on Linux and we need to get a solution
for 3.6 and 3.5.5. :wink:

Anyway, let's move the discussion into bugzilla where it belongs. I have
create the bug https://bugs.freedesktop.org/show_bug.cgi?id=50415 for
this :slight_smile:

Best Regards,
Petr

#6

Very good, Petr, I'll subscribe the bug.

Ciao