Bug 31938 - Win32 installer is not BrOffice branded
Summary: Win32 installer is not BrOffice branded
Status: CLOSED FIXED
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: UI (show other bugs)
Version:
(earliest affected)
3.3.0 Beta3
Hardware: Other All
: medium blocker
Assignee: Fridrich Strba
URL:
Whiteboard:
Keywords:
Depends on:
Blocks: 31865
  Show dependency treegraph
 
Reported: 2010-11-26 08:39 UTC by Michael Meeks
Modified: 2011-01-13 01:07 UTC (History)
4 users (show)

See Also:
Crash report or crash signature:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Michael Meeks 2010-11-26 08:39:05 UTC
We should show BrOffice branding in the windows installer, when run in the pt_BR locale.
Comment 1 Petr Mladek 2010-11-26 12:12:24 UTC
Fridrich, could you please look at it?

Note that it is considered as a blocker for 3.3 release.
Comment 2 Michael Meeks 2010-11-26 13:07:44 UTC
I am digging into this myself now - what a read the NSIS code is ! :-> wow.
Comment 3 Michael Meeks 2010-11-26 13:31:27 UTC
So ... it seems that the command to be using is SetBrandingImage:

!macro BIMAGE IMAGE PARMS
        Push $0
        GetTempFileName $0
        File /oname=$0 "${IMAGE}"
        SetBrandingImage ${PARMS} $0
        Delete $0
        Pop $0
!macroend

and it looks like all of this dynamic goodness is exported to the macro language quite nicely:

Section ""
        ; You can also use the BI_NEXT macro here...
        MessageBox MB_YESNO "We can change the branding image from within a section too!$\nDo you want me to change it?" IDNO done
                !insertmacro BIMAGE "${NSISDIR}\Contrib\Graphics\Wizard\nsis.bmp" ""
        done:
        WriteUninstaller uninst.exe
SectionEnd

I suggest that we do a certain amount of in-lining of the (URGH!) awful MUI.nsh -> System.nsh logic; and/or if we can clobber this macro:

!macro MUI_HEADERIMAGE_INIT UNINSTALLER

to be a tad more clever.
Comment 4 Michael Meeks 2010-11-26 14:20:37 UTC
Lots more notes on this in build/doc/nsis-broffice.txt - the fun part is trying to wind back the locale detection into the scripting language, so we can create a suitable conditional here :-)

Perhaps I'm just doing that wrong; possibly we want a translated filename string that is only translated in portugese brazilian - not sure; worth investigating.
Comment 5 Fridrich Strba 2010-11-29 00:37:55 UTC
http://nsis.sourceforge.net/Detect_User_Locale_INFO(Language,_Country,_LangID...)
has some information that could be useful
Comment 6 Fridrich Strba 2010-11-29 00:43:18 UTC
@Michael: Thanks for entering yourself into it and compensating my stupidity :)
Comment 7 Michael Meeks 2010-11-30 04:38:42 UTC
Progressing reasonably nicely ... but very very slow to do a test iteration: this is Windows after all. I hope to have it done early this afternoon.
Comment 8 Michael Meeks 2010-11-30 06:21:48 UTC
I've implemented, and merged the artwork branding to the libreoffice-3-3 branch.
Unfortunately, the string branding is still not done ;-)

So we get BrOffice artwork, and LibreOffice strings. Working on fixing that - but by far the easiest way to test that is to use the product name - though IMHO we should switch to keying from locale name for at least a consistent art/strings product.

IMNSHO it is not feasible to have dynamic installer strings depending on binary name. Anyhow - getting there :-)
Comment 9 Michael Meeks 2010-11-30 07:21:34 UTC
I added a new PRODUCTNAME_BR variable to openoffice.lst - which is where the ulf files get their %PRODUCTNAME substitutions from;

It is just a matter now of tweaking the pt_BR translations to use %PRODUCTNAME_BR and we have a translated installer.
Comment 10 Michael Meeks 2010-11-30 08:58:30 UTC
finally pushed the %PRODUCTNAME_BR patch to l10n/ 's .sdf files; all the tests suggest that it should pop out of the end fully localized ...
Comment 11 sophie 2011-01-13 01:07:30 UTC
Closing it, if there is still problem, please reopen. Sophie