| Summary: | Language selection is not possible with silent install | ||
|---|---|---|---|
| Product: | LibreOffice | Reporter: | Andras Timar <timar74> |
| Component: | Installation | Assignee: | Andras Timar <timar74> |
| Status: | RESOLVED FIXED | ||
| Severity: | normal | CC: | timur |
| Priority: | medium | ||
| Version: | 3.5.4 release | ||
| Hardware: | Other | ||
| OS: | Windows (All) | ||
| See Also: |
https://bugs.freedesktop.org/show_bug.cgi?id=40481 https://bugs.freedesktop.org/show_bug.cgi?id=54585 |
||
| Whiteboard: | target:3.6.0 target:3.5.5 | ||
| Crash report or crash signature: | Regression By: | ||
| Bug Depends on: | |||
| Bug Blocks: | 37361 | ||
|
Description
Andras Timar
2012-05-30 09:32:48 UTC
Andras Timar committed a patch related to this issue. It has been pushed to "master": http://cgit.freedesktop.org/libreoffice/core/commit/?id=a77d16835504b4f82b6b9e59c213eea8a879219c fdo#50509 MSI: UI language selection from command line (e.g. silent install) If the UI_LANGS property is set, the language guessing heuristic is switched off, and user can define explicitely, what languages should be installed. E.g.: msiexec /i LibO_...._.msi UI_LANGS=en_US,de,fr,hu It will install English (US), German, French, and Hungarian. There are still some minor issues with language selection, because for example pt_BR also selects pt implicitely, but this is the same what we have with automatic language selection. When the user tries to fool the installer by giving invalid language codes, installer will fall back to en_US. Also, en_US is not installed by default, unlike with the automatic selection. Andras Timar committed a patch related to this issue. It has been pushed to "libreoffice-3-5": http://cgit.freedesktop.org/libreoffice/core/commit/?id=743e3176244691f5d437ef38cf4eeba3d89a0af5&g=libreoffice-3-5 fdo#50509 MSI: UI language selection from command line (e.g. silent install) It will be available in LibreOffice 3.5.5. From before, we use ADDLOCAL=ALL and then REMOVE for dictionaries. Are UI languages affected by this? It's not clear about IS<lcid>. Should it be UI_LANGS=en-us,de-de,fr,hu and not UI_LANGS=en_US,de,fr,hu, like in http://msdn.microsoft.com/en-us/library/ms533052%28v=vs.85%29.aspx? (In reply to comment #4) > From before, we use ADDLOCAL=ALL and then REMOVE for dictionaries. > Are UI languages affected by this? No, they are not. This patch has no effect on dictionaries. > > It's not clear about IS<lcid>. Should it be UI_LANGS=en-us,de-de,fr,hu and not > UI_LANGS=en_US,de,fr,hu, like in > http://msdn.microsoft.com/en-us/library/ms533052%28v=vs.85%29.aspx? IS<lcid> properties are deprecated. I'll remove them in 3.7. They were not useful, because all were set to 1. Typically users want to install a few languages only. It is awkward to set 100+ IS<lcid> properties to 0 in the command line. As for en_US or en-us, it really does not matter. It was easier to implement with underscores, and I don't see the point in changing it. UI_LANGS works fine if there is no LO installation present on a computer. But, if there is an installation already, UI_LANGS doesn't change UI languages. This is a problem because if we have an installation that has all UI languages and want just to remove them, we can't do it by reinstallation. Dictionaries on the other hand can be modified. Can you please comment or change this behavior? PS. If it doesn't seems probable, that's what happened to us. Software management installed LO 3.6.0 as an upgrade to our 3.5.4, with all UI languages which made LO very slow. It was not on the list of managed programs at all, but how it happened is a different issue. New installation of LO 3.6.1 over that couldn't solve the problem. |