Issue 66919 - Export as PDF dialog is missing labels en-GB build
Summary: Export as PDF dialog is missing labels en-GB build
Status: CLOSED DUPLICATE of issue 79665
Alias: None
Product: ui
Classification: Code
Component: code (show other issues)
Version: OOo 2.0.3
Hardware: All All
: P3 Trivial with 8 votes (vote)
Target Milestone: OOo 2.4
Assignee: ivo.hinkelmann
QA Contact: issues@ui
URL:
Keywords:
: 66799 69813 71972 (view as issue list)
Depends on:
Blocks:
 
Reported: 2006-07-01 19:58 UTC by shaunmcdonald131
Modified: 2008-11-05 20:56 UTC (History)
11 users (show)

See Also:
Issue Type: DEFECT
Latest Confirmation in: ---
Developer Difficulty: ---


Attachments
Screenshot of the dialog with missing labels (19.56 KB, image/png)
2006-07-01 19:59 UTC, shaunmcdonald131
no flags Details
Menu bug screenshot from 69813 (15.23 KB, image/jpeg)
2006-12-23 15:45 UTC, jjmckenzie
no flags Details
Missing menu text from issue 62985 (3.22 KB, image/png)
2006-12-23 15:56 UTC, jjmckenzie
no flags Details
More missing menu item pictures from Issue 62985. (12.26 KB, image/png)
2006-12-23 16:01 UTC, jjmckenzie
no flags Details
A patch that does not work, using a suggestion above (1.17 KB, patch)
2007-03-02 21:49 UTC, shaunmcdonald131
no flags Details | Diff

Note You need to log in before you can comment on or make changes to this issue.
Description shaunmcdonald131 2006-07-01 19:58:08 UTC
On PPC build for OOo 2.0.3, the 'File' > 'Export as PDF...' dialog after the save dialog is missing all the 
labels. Using Mac OS X 10.4.7, Java 1.5.

Will attach an image of the dialog.

The export works fine, except you cannot know what options are available.
Comment 1 shaunmcdonald131 2006-07-01 19:59:36 UTC
Created attachment 37452 [details]
Screenshot of the dialog with missing labels
Comment 2 shaunmcdonald131 2006-07-02 01:09:18 UTC
Just checked en-US PPC build and it does not have a problem. It appears to be an issue with the en-GB 
build. 
Are other locales affected? (from reports from ericb no on the french build)
Are other OSes affected? 

You will need to check with the user interface language set to "English (UK)"
Comment 3 ace_dent 2006-07-02 12:27:19 UTC
Tested with OOoDev 2.0.3 680m173, PC WinXP.

Vanilla build, switched UI to en_GB. Could not reproduce the problem.
->'smsm1': Please provide link to downloads of en_GB localised builds and full
version details for your OOo build. (Press Ctrl+ S, D then T when viewing the
'About' dialogue).

Regards,
Andrew
Comment 4 shaunmcdonald131 2006-07-02 14:01:56 UTC
I got the build from:
ftp://anonymous@ooopackages.good-day.net:21/pub/OpenOffice.org/MacOSX/2.0.3rc7/
the PPC build en-GB exhibits the problem. It does not matter whether it is run on PPC or Intel hardware 
(using Rosetta).

built by maho 680m7 (build 9044)

I'm currently downloading the Intel en-GB build to see if that exhibits the problem too.

Eric b's build ftp://ftp.cusoo.org/ooo/MacOSX/INTEL/m173/en-US/OpenOffice.org-2.0.3_en-US.dmg
does not have the issue.

I'll need to get back to you later on the build id for eric b's build.
Still awaiting PPC version of Eric b's build to test that.
Comment 5 shaunmcdonald131 2006-07-02 15:24:41 UTC
I've just tested maho's intel build and it is exhibiting the same problem for en_GB.

OOo 2.0.3 built by maho, 680m7 build: 9044

Using the following build, the problem does not exist:

OpenOffice.org 2.0 created by Eric Bachard 680m173 build: 9040

It would appear that eric's build is from slightly older source code.

Hope these build numbers help in determining the problem.
Comment 6 eric.bachard 2006-07-02 15:43:40 UTC
*** Issue 66799 has been marked as a duplicate of this issue. ***
Comment 7 eric.bachard 2006-07-02 15:45:49 UTC
Locale concerned : en-GB (other are not, AFAIK)

OS:  Windows, Mac OS X , probably other
Comment 8 taylormc 2006-07-03 11:19:20 UTC
I originally experienced the same problem as this under XP SP1, using the en-GB
2.0.3 rc7 build (documented as 66799). I have now downloaded and installed the
vanilla 2.0.3 rc7 build, confirmed correct behaviour; downloaded en-GB 2.0.3 rc7
langpack and installed, confirmed behaviour as documented here; uninstalled
langpack, confirmed reversion to correct behaviour.
Hope this is helpful.
Comment 9 shaunmcdonald131 2006-07-03 12:56:07 UTC
smsm1 --> taylormc:
What you have just tested, confirms that the problem exists with the en-GB lang pack.
Thank you.
Comment 10 shaunmcdonald131 2006-07-04 08:44:45 UTC
See issue http://www.openoffice.org/issues/show_bug.cgi?id=65606 for very similar issue.
Comment 11 pavel 2006-07-09 15:54:24 UTC
I'll have a look on this issue next week.
Comment 12 pavel 2006-07-14 13:29:16 UTC
Interesting.

I pick one string that is not shown:

pavel@linux:~/.ooo/ooo_OOC680_m7_src/filter/source/pdf> grep
RB_LOSSLESSCOMPRESSION localize.sdf |grep en-GB
filter  source\pdf\impdialog.src        0       radiobutton    
RID_PDF_EXPORT_DLG      RB_LOSSLESSCOMPRESSION                  156     en-GB  
~Lossless compression                   2002-02-02 02:02:02
pavel@linux:~/.ooo/ooo_OOC680_m7_src/filter/source/pdf> 

It is in localize.sdf file. On the other hand:

oo@oo:~/BuildDir/ooo_SRC680_m176_src/filter/unxlngi6.pro/bin> ls -al pdffil*res
-rwxrwxr--    1 oo       users        6082 Jul 14 10:57 pdffilter680cs.res
-rwxrwxr--    1 oo       users        5382 Jul 14 10:57 pdffilter680en-GB.res
-rwxrwxr--    1 oo       users        5904 Jul 14 10:57 pdffilter680en-US.res
oo@oo:~/BuildDir/ooo_SRC680_m176_src/filter/unxlngi6.pro/bin> grep "Lossless" *res
Binary file pdffilter680en-US.res matches
oo@oo:~/BuildDir/ooo_SRC680_m176_src/filter/unxlngi6.pro/bin> 

Czech string is translated and as such, it appears in cs*res file.

-> ivo: can you please verify the same for 2.0.3 final and investigate?
Comment 13 pavel 2006-07-14 15:59:56 UTC
oo@oo:~/BuildDir/ooo_SRC680_m176_src/filter> grep en-GB
./unxlngi6.pro/misc/pdffilter/impdialog.src|wc -l
      7
oo@oo:~/BuildDir/ooo_SRC680_m176_src/filter> grep en-US
./unxlngi6.pro/misc/pdffilter/impdialog.src|wc -l
     47
oo@oo:~/BuildDir/ooo_SRC680_m176_src/filter> 
Comment 14 ivo.hinkelmann 2006-07-19 11:37:21 UTC
tools/source/rc/isofallback.cxx:

sal_Bool GetIsoFallback( ByteString& rLanguage )
{
    rLanguage.EraseLeadingAndTrailingChars();
    if( rLanguage.Len() ){
        xub_StrLen nSepPos = rLanguage.Search( '-' );
        if ( nSepPos == STRING_NOTFOUND ){
            if ( rLanguage.Equals("en"))
            {
                // en -> ""
                rLanguage.Erase();
                return false;
            }

... means en-GB will be rated as a missing en-US string . Thats a bug!
Comment 15 mike_hall 2006-07-19 14:58:48 UTC
With 176 on Win XP the labels show fine (normal behavious), with en_gb dict
loaded and default language set to en_gb

Behaviour as described with 2.0.3 as released, which was a clean install, same
dict and language settings.
Comment 16 ivo.hinkelmann 2006-07-21 14:48:02 UTC
the resmgr looks also weird regarding "en" , are you sure this is fixed in the
current version ?
Comment 17 mike_hall 2006-07-21 21:33:01 UTC
Maybe it's just a workaround. I installed m176 from the OOo mirrors site, so
it's not localised. Then loaded the GB dict etc and set the default language to
UK English. PDF export has the labels. AFAIK doing it that way gives
functionality equivalent to the localisation I loaded for 2.0.3 from one of the
UK Mirrors, but I haven't directly applied the 'language pack' to the dev version.
Comment 18 shaunmcdonald131 2006-08-09 14:28:44 UTC
Not fixed in m180 (maho's build)
Comment 19 ivo.hinkelmann 2006-08-09 15:15:33 UTC
there is a issue within the fallback mechanism , I was not yet able to track the
root cause down. As a workarround please just translate those missing strings
Comment 20 ivo.hinkelmann 2006-08-09 16:28:25 UTC
I added the missing strings to filter module ( cws localize12 ) , but the root
cause is not yet fixed
Comment 21 shaunmcdonald131 2006-08-09 22:55:03 UTC
ihi: Thank you. Will it appear in build 181?
Comment 22 ivo.hinkelmann 2006-08-10 10:43:03 UTC
no but it is part of cws localize12 which will be integrated soon
Comment 23 ivo.hinkelmann 2006-08-14 17:36:31 UTC
-> 2.1
Comment 24 ivo.hinkelmann 2006-10-17 16:05:55 UTC
I have to retarget this one to 2.x
Comment 25 shaunmcdonald131 2006-12-02 18:46:52 UTC
This appears to be an issue in a number of other places too. Examples include
data sources, which has missing items in the popup menu on the left hand side
browser; and right click on the points in a presentation.
Comment 26 pavel 2006-12-12 08:55:33 UTC
Ivo: can we make this happen for 2.2?
Comment 27 rene 2006-12-14 11:28:56 UTC
ihi: is there any preliminary patch to test?
Comment 28 ivo.hinkelmann 2006-12-14 17:42:42 UTC
no, the problem is not yet fixed nor any patches available
Comment 29 ivo.hinkelmann 2006-12-15 16:30:51 UTC
Hi PL,

can you please have a look onto resmgr.cxx

InternalResMgr* ResMgrContainer::getResMgr
...
        if( nTries == 0 && !aLocale.Language.equalsIgnoreAsciiCaseAscii( "en" ) )
        {
            // locale fallback failed
            // fallback to en-US locale
            nTries = 2;
            aLocale.Language = OUString( RTL_CONSTASCII_USTRINGPARAM( "en" ) );
            aLocale.Country  = OUString( RTL_CONSTASCII_USTRINGPARAM( "US" ) );
            aLocale.Variant = OUString();
        }
...

and 

InternalResMgr* ResMgrContainer::getNextFallback( InternalResMgr* pMgr )
{
    com::sun::star::lang::Locale aLocale = pMgr->aLocale;
    if( aLocale.Variant.getLength() )
        aLocale.Variant = OUString();
    else if( aLocale.Country.getLength() )
        aLocale.Country = OUString();
    else if( ! aLocale.Language.equalsIgnoreAsciiCaseAscii( "en" ) )
    {

don't look en-GB friendly. Is the the cause for the missing en-GB fallbacks in
res files?
Comment 30 philipp.lohmann 2006-12-15 17:45:57 UTC
yes, could be :-(

!aLocale.Language.equalsIgnoreAsciiCaseAscii( "en" )

should probably read

! ( aLocale.Language.equalsIgnoreAsciiCaseAscii( "en" ) &&
    aLocale.Country.equalsIgnoreAsciiCaseAscii( "us" ) )

in both instances
Comment 31 jjmckenzie 2006-12-23 15:41:58 UTC
*** Issue 69813 has been marked as a duplicate of this issue. ***
Comment 32 jjmckenzie 2006-12-23 15:45:37 UTC
Created attachment 41675 [details]
Menu bug screenshot from 69813
Comment 33 jjmckenzie 2006-12-23 15:46:50 UTC
Adding reporter and cc's from 69813 to this issue.

James McKenzie
Comment 34 jjmckenzie 2006-12-23 15:50:00 UTC
*** Issue 62985 has been marked as a duplicate of this issue. ***
Comment 35 jjmckenzie 2006-12-23 15:56:19 UTC
Created attachment 41676 [details]
Missing menu text from issue 62985
Comment 36 jjmckenzie 2006-12-23 16:01:29 UTC
Created attachment 41677 [details]
More missing menu item pictures from Issue 62985.
Comment 37 aziem 2006-12-23 16:20:45 UTC
I am not sure my issue 62985 is the same as this because (1) I am using US
English only, (2) the problem only shows up after upgrading (3) in Windows, and
(4) the problem disappears when deleting the profile directory.
Comment 38 epost 2007-01-22 14:15:43 UTC
set target to 2.3 as it does not seem realistic that this will be implemented
until the 2.2 code freeze
Comment 40 shaunmcdonald131 2007-03-02 21:49:57 UTC
Created attachment 43492 [details]
A patch that does not work, using a suggestion above
Comment 41 shaunmcdonald131 2007-03-03 00:16:39 UTC
I have attached the patch that does not work (for use in a process of
elimination). I produced it based on a suggestion above. It could be that
something else needs to be done to be able to get it to work.
Comment 42 ivo.hinkelmann 2007-03-15 15:32:16 UTC
pl, please take over. I failded to find the root cause. The resmgr don't
fallback for all en-* languages to en-US ....
Comment 43 philipp.lohmann 2007-03-26 15:21:48 UTC
pl->ihi: after having some trouble to reproduce the problem, i finally got to
the point of this.

1. problem: in the produced intermediate .srs file that gets merged from
localize.sdf and the .src files there is always a default entry
Text = ""
for any string. So resource fallback does not come into play here, because
building the resource will fallback to the default entry if there is no
specialized "en-GB" entry - which now happens to be an empty string.

2. problem: even if the empty default strings are removed, this only ends up
with resource objects with no "Text" attribute. This is legal syntax, the text
attribute of all the objects is then an empty string, which is still valid. So
still no resource fallback in action.

resource fallback will only come into play if there is a named resource object
missing (one with an ID); in which case resource fallback already works as
designed for en-GB (I checked).

proposed solution: do not emit Text="" but instead Text=<whatever is there for
Text[en-US]>
Comment 44 lohmaier 2007-05-12 10:52:09 UTC
*** Issue 71972 has been marked as a duplicate of this issue. ***
Comment 45 ivo.hinkelmann 2007-07-09 12:54:53 UTC
fixed in cws l10ntooling02
Comment 46 shaunmcdonald131 2007-07-12 21:50:10 UTC
From my compilation of the CWS Tcws_src680_l10ntooling02 (module transex3) with the master 
TSRC680_m214, and the lang en-GB I still get the problem of labels being missing.

Comment 47 ivo.hinkelmann 2007-07-13 12:32:50 UTC
srs files are created by rsc so this is your issue
Comment 48 philipp.lohmann 2007-07-13 12:42:21 UTC
but still srs files are never better than the src files they're being made of.
Comment 49 ivo.hinkelmann 2007-07-13 13:05:31 UTC
there is no Text="" produced by transex3
Comment 50 philipp.lohmann 2007-07-13 13:10:33 UTC
So how do I use that tool ?
Comment 51 ivo.hinkelmann 2007-07-13 13:18:32 UTC
I propose you use "Text[en-US]=" instead of "Text=" as default entry
Comment 52 philipp.lohmann 2007-07-13 13:24:03 UTC
That doesn't answer my question. Also it is not a very convincing proposal; the
rsc syntax has a fallback value from its beginnings; so why not use it instead
of qualifying everything with [en-US] ?
Comment 53 ivo.hinkelmann 2007-07-13 13:39:22 UTC
I guess I don't understand your first question. On the other hand in the past
"Text =" was the developer English. We changed the meaning of that to "do not
translate this string". Thus the correct fallback would be:

if there is an en-US entry use it as fallback
else take the "Text = " entry
Comment 54 philipp.lohmann 2007-07-13 13:54:28 UTC
What do you mean "you changed the meaning" ? rsc has a certain syntax, clean and
simple. This is like saying I don't want x +=2 to mean increase x by 2 anymore
but instead emit the smell of roses. And then file a bug to the compiler developer.
Comment 55 philipp.lohmann 2007-07-19 08:46:19 UTC
This is basically duplicate to issue 79665 which is supposed to implement a more
elaborate fallback mechanism instead of the single fallback we have now working.
Comment 56 shaunmcdonald131 2007-07-19 10:16:26 UTC
I thought that at the moment, any language should automatically fallback to en-US. However this is not 
happening as per this issue with the en-XX, where XX is not US. This may be occurring with with langs 
too.
Comment 57 ivo.hinkelmann 2007-08-08 15:02:58 UTC
full en-GB is merged into OOo 2.3 to workaround this bug. Hopefully this will be
solved with the change for language variants
Comment 58 ivo.hinkelmann 2008-02-20 12:54:33 UTC
.

*** This issue has been marked as a duplicate of 79665 ***
Comment 59 Mechtilde 2008-11-05 20:56:30 UTC
close the duplicate