Bug 31770 - BrOffice brand and LibreOffice
Summary: BrOffice brand and LibreOffice
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Localization (show other bugs)
(earliest affected)
3.3.0 Beta3
Hardware: All All
: high major
Assignee: Petr Mladek
Depends on:
Blocks: 31865
  Show dependency treegraph
Reported: 2010-11-19 10:23 UTC by Olivier Hallot
Modified: 2011-01-12 08:33 UTC (History)
2 users (show)

See Also:
Crash report or crash signature:

about box showing correct picture of brand and wrong product name (23.46 KB, image/png)
2010-11-19 10:26 UTC, Olivier Hallot
possible solution using locale and configmr (1.26 KB, patch)
2010-11-30 12:52 UTC, Petr Mladek
Proposed fix for the help branding (4.04 KB, patch)
2010-12-09 11:40 UTC, Petr Mladek

Note You need to log in before you can comment on or make changes to this bug.
Description Olivier Hallot 2010-11-19 10:23:45 UTC
BrOffice is the name of LibreOffice in Brazil (pt-BR) as demanded and fullfilled (partially).

The graphics attached here shows all:

The image (bitmap) is correct. Good!

All references to LibreOffice in the text should be changed to BrOffice. This is actually done by setting 


in compile time.

On a multi-language package ths may require tweaking, but if we stick with just pt-BR it may be easier to make the BrOffice package.

We will appreciate to have a single language (pt-BR) package to test. The error may vanish by itself.
Comment 1 Olivier Hallot 2010-11-19 10:26:18 UTC
Created attachment 40410 [details]
about box showing correct picture of brand and wrong product name

Please look also on references of OpenOffice.org. We may have to change the string in the about box.
Comment 2 Don't use this account, use tml@iki.fi 2010-11-22 00:44:47 UTC
Is a recompilation really necessary? That sucks, the ideal would be to be able to have the same binaries and just have them expand %PRODUCTNAME differently depending on locale.
Comment 3 Olivier Hallot 2010-11-22 01:04:07 UTC
%PRODUCTNAME was introduced to allow vendors to name the product as they wish. The concept is different from the locale.

OpenOffice.org did a separate package for us in the past.
Comment 4 Rainer Bielefeld Retired 2010-11-28 06:29:06 UTC
I don't know anything concerning this BrOffice branding - there is no conflict with an OOo BrOffice?
I will nominate this Bug as 3.3 blocker.
Comment 5 Olivier Hallot 2010-11-28 14:42:47 UTC
Conflict: Suposedly not. We demanded them to drop the name, but I have not checked.

Thanks for nominating this as blocker.
Comment 6 Petr Mladek 2010-11-30 02:58:56 UTC
I am going to look at it.
Comment 7 Michael Meeks 2010-11-30 04:35:24 UTC
We are not doing custom builds for a specific locale; -but- we should have code to adapt the productname to broffice in this locale.
I am torn as to how to do that.

If the string appears in a user-interface string; then it should be translated - as such, I suggest we use a %PRODUCTNAME_BR% for that specific translation - so we get BrOffice instead. That will require a little sed and some work - but leave the core code clean and fairly free from hacks.

Then we can easily fall back, if --enable-broffice is not passed at compile time (this is the default of course), then %PRODUCTNAME_BR% would be %PRODUCTNAME%

Petr - can you use that approach ? :-)

This may miss RC1, and is not a stopper IMHO - we have time to fix it for RC2; my main concern is the Win32 installer branding...
Comment 8 Petr Mladek 2010-11-30 12:52:21 UTC
Created attachment 40680 [details]
possible solution using locale and configmr

I tried to play with the %PRODUCTNAME_BR. There were more locations where the %PRODUCTNAME was substituted. I tries to change some and it still did not renamed all locations.

Though, all locations got the right product name from confimgr. I tried to return the name according to the locale and it worked fine. See the attached diff.

It works the same way like the splash screen and about dialog picture. They are displayed also according to the locale.

Michael, what do you think?
Comment 9 Petr Mladek 2010-12-01 05:12:20 UTC
I have commited the patch from the comment #8 for LibO-3.3-rc1. It seems to works fine.

We could come with a better solution in the future builds.
Comment 10 Michael Meeks 2010-12-02 05:23:27 UTC
If we are configured with --disable-broffice - then we should not do that, so:


in the makefile.mk, and some


around it would make it perfect :-)

Thanks !
Comment 11 Petr Mladek 2010-12-03 07:19:35 UTC
Just commited the changes suggested by Michael in the comment #10. It seems to work well => I would consider it as FIXED.

Note that it should work in the upcomming LibO-3.3-rc1 build.
Comment 12 Petr Mladek 2010-12-06 06:41:24 UTC
Hmm, I still see LibreOffice in the help content. It shows BrOffice in other location => REOPENED

Strange, I think that it worked when I tested my fix :-(
Comment 13 Rainer Bielefeld Retired 2010-12-08 07:59:29 UTC
Please check whether some pbservations from "Bug 32229 - Adjusts in the name of LO in pt-BR to "BrOffice" in the installer and menus" block this one!
Comment 14 Petr Mladek 2010-12-09 11:40:05 UTC
Created attachment 40959 [details]
Proposed fix for the help branding

I modified both xmlhelp/source/treeview and xmlhelp/source/cxxhelp/provider. 

I did not want to duplicate the logic:

--- cut ---
     LanguageType nType = MsLangId::getSystemUILanguage();
         sBrandName = OUString::createFromAscii("BrOffice");
--- cut ---

So, I rather called the already-patched ::utl::ConfigManager::GetDirectConfigProperty

It added the build/link dependency on unotools. I hope that it is acceptable. It looks fine from the split-build-point-of-view.

Note that I need to replace #define PRODUCTNAME with enum. Otherwise, it broke the ::utl::ConfigManager::PRODUCTNAME parameter. The enum was alrady used in  xmlhelp/source/treeview
Comment 15 Michael Meeks 2010-12-13 06:28:51 UTC
Patch looks great to me Petr; please commit it - if we're convinced that this doesn't break the split build / dependency graph wrt. the unotools dep.
Comment 16 Petr Mladek 2010-12-14 08:41:01 UTC
The fix for the help branding has been commited as

Comment 17 Petr Mladek 2010-12-14 08:43:46 UTC
really marked as fixed.

I will remove the dependency on the bug 32229. I will nominate it as a separate blocker. IMHO, The long dependency tries are not much practical.
Comment 18 sophie 2011-01-12 08:33:20 UTC
Closing - Sophie