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.
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.
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.
%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.
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.
Conflict: Suposedly not. We demanded them to drop the name, but I have not checked.
Thanks for nominating this as blocker.
I am going to look at it.
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...
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?
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.
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 :-)
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.
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 :-(
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!
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();
if ( nType == LANGUAGE_PORTUGUESE_BRAZILIAN )
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
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.
The fix for the help branding has been commited as
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.
Closing - Sophie