Bug 33189 - l10n: Missing parts in Print dialog of Calc when translation is not complete
Summary: l10n: Missing parts in Print dialog of Calc when translation is not complete
Status: CLOSED FIXED
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Localization (show other bugs)
Version:
(earliest affected)
3.3.0 release
Hardware: Other Linux (All)
: medium normal
Assignee: Andras Timar
QA Contact:
URL:
Whiteboard:
Keywords:
: 33764 33865 34343 (view as bug list)
Depends on:
Blocks:
 
Reported: 2011-01-16 10:26 UTC by Gökçen Eraslan
Modified: 2011-06-03 02:00 UTC (History)
5 users (show)

See Also:
Crash report or crash signature:


Attachments
Example file to try printing a range (30.75 KB, application/vnd.oasis.opendocument.spreadsheet)
2011-01-16 10:26 UTC, Gökçen Eraslan
Details
Screenshot describing the problem (208.47 KB, image/png)
2011-01-16 10:28 UTC, Gökçen Eraslan
Details
Screenshot of the same system, same file and same LO version with C locale (144.79 KB, image/png)
2011-02-08 05:50 UTC, Gökçen Eraslan
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Gökçen Eraslan 2011-01-16 10:26:19 UTC
Created attachment 42103 [details]
Example file to try printing a range

I can't print a range in an ODS file. When I try to print the file, I can see that it's 13 pages in length but I can't select print pages between 3-4 only.
Comment 1 Gökçen Eraslan 2011-01-16 10:28:01 UTC
Created attachment 42104 [details]
Screenshot describing the problem

Title is "Range and copies" but there is no range input field.
Comment 2 Gökçen Eraslan 2011-01-29 03:58:20 UTC
Any news about that? I can see that same version of LibreOffice in Ubuntu shows Range fields[1]. Is this related to a compile parameter? So I can try any if you want.

[1] http://bugs.pardus.org.tr/attachment.cgi?id=6620
Comment 3 Gökçen Eraslan 2011-02-08 05:49:30 UTC
Now I've found the reason behind this bug, even if I know nobody is interested. 

If I change locale to C or en-US, bug is gone, so this is a Turkish locale specific problem. 

For more information about Turkish locale bugs:

http://www.mattryall.net/blog/2009/02/the-infamous-turkish-locale-bug
http://java.sys-con.com/node/46241
Comment 4 Gökçen Eraslan 2011-02-08 05:50:32 UTC
Created attachment 43099 [details]
Screenshot of the same system, same file and same LO version with C locale
Comment 5 Andras Timar 2011-02-18 01:36:59 UTC
L10n bug, I take it.
Comment 6 Andras Timar 2011-02-18 14:49:44 UTC
The following translations are affected (in LibreOffice 3.3.1 RC2):
af, as, be-BY, bo, br, brx, bs, ca-XV, cy, dgo, dz, el, eo, et, fa, he, hi, id, ka, kk, kok, ks, ku, lo, lt, mai, mk, ml, mn, mni, my, ne, nn, nr, ns, oc, om, pa-IN, ro, rw, sa-IN, sat, sd, si, sq, ss, st, sw-TZ, ta, tg, th, tn, tr, ts, uk, uz, ve, xh, zu

When translation of the StringArray SCSTR_PRINT_OPTIONS in calc/sc/source/ui/src/scstring.src is not complete, the resource compiler somehow fails to fallback to en-US. Incomplete traslation results in incomplete .res files (e.g. sctr.res).

LibreOffice checks if this StringArray contains 19 elements (calc/sc/source/ui/unoobj/docuno.cxx). If it doesn't, then the widgets are not put on the screen. 

Possible workaround: complete the translations or put English strings there. It would be better to fix the original bug, though.
Comment 7 Zeki Bildirici 2011-02-19 08:50:52 UTC
Hi,

> LibreOffice checks if this StringArray contains 19 elements
> (calc/sc/source/ui/unoobj/docuno.cxx). If it doesn't, then the widgets are not
> put on the screen. 
> 
> Possible workaround: complete the translations or put English strings there. It
> would be better to fix the original bug, though.

I have just complated the translation of 
https://translations.documentfoundation.org/tr/libo33x_ui/sc/source/ui/src.po/translate/

and on Pootle. Now https://translations.documentfoundation.org/tr/libo33x_ui/sc/ is translated by %100.

Is it ok for this bug, or some other files  needs to be translated?
Comment 8 Andras Timar 2011-02-19 08:57:42 UTC
> Is it ok for this bug, or some other files  needs to be translated?

For Turkish it is OK, for rest of the affected languages it is not. :) Thanks for your work but we need to find a general solution in order to close this bug.
Comment 9 Andras Timar 2011-02-19 10:52:37 UTC
I investigated further. All occurences of ItemList are susceptible to this bug. Now ItemLists must be translated fully or not at all. Partial translation leads to error. Fortunately there are not many ItemLists in the source (and some are not used).

StringArray FOO_BAR
   {
       ItemList [ en-US ] =
       {
           < "Item1" ; 1; > ;
           < "Item2" ; 2; > ;
           < "Item3" ; 3; > ;
           < "Item4" ; 4; > ;
       };
   };

When only Item1 and Item3 are translated in the SDF file, then we get:

StringArray FOO_BAR
   {
       ItemList [ xx ] =
       {
           < "TranslatedItem1" ; 1; > ;
           < "TranslatedItem3" ; 3; > ;
       };
   };

instead of:

StringArray FOO_BAR
   {
       ItemList [ xx ] =
       {
           < "TranslatedItem1" ; 1; > ;
           < "Item2" ; 2; > ;
           < "TranslatedItem3" ; 3; > ;
           < "Item4" ; 4; > ;
       };
   };

Affected languages in 3.3.1 are the following (the list in comment 6 was wrong, if resource is not translated at all, then it is fine):
as, be-BY, bo, br, bs, ca-XV, dz, el, he, hi, id, ku, lt, ml, my, om, pa-IN, si, sq, ta, th, tr, uk, uz
Comment 10 Petr Mladek 2011-02-21 03:14:41 UTC
It looks like a regression of http://www.openoffice.org/issues/show_bug.cgi?id=74982 or something similar.
Comment 11 Andras Timar 2011-02-24 22:13:19 UTC
*** Bug 33865 has been marked as a duplicate of this bug. ***
Comment 12 Andras Timar 2011-02-25 08:14:19 UTC
*** Bug 34343 has been marked as a duplicate of this bug. ***
Comment 13 Andras Timar 2011-02-25 08:21:39 UTC
*** Bug 33764 has been marked as a duplicate of this bug. ***
Comment 14 Andras Timar 2011-02-26 13:09:03 UTC
diff --git a/l10ntools/source/export.cxx b/l10ntools/source/export.cxx
index 118ddb3..ccef639 100644
--- a/l10ntools/source/export.cxx
+++ b/l10ntools/source/export.cxx
@@ -1561,7 +1566,7 @@ void Export::InsertListEntry( const ByteString &rText, const ByteString &rLine )
         else{
             const ByteString sPlist("list");
             ByteString a( pResData->sGId );
-            a.Append( "." );
+            if ( a.Len()) a.Append( "." );
             a.Append( pResData->sId );
             sal_Int64 x = nListIndex+1;
             ByteString b( ByteString::CreateFromInt64( x ) );

This patch makes the fallback work, but unfortunately it triggers another bug.
Some type of resources (after #define) are merged twice and the second merge is wrong.

E.g.:

#define  _ST_NONE_LIST              \
        StringList [en-US]=    \
        {                           \
            < "< none >" ; > ;        \
        };

It is merged like this:

#define  _ST_NONE_LIST              \
        StringList [en-US]=    \
        {                           \
            < "< none >" ; > ;        \
        };\
	StringList [ hu ] = \
	{\
		 < "<semmi>" ; > ;\
	};StringList [ hu ] =
	{
		 < "< none >" ; > ;
	};

The second occurence of [ hu ] is wrong (untranslated + syntax error).
Comment 15 Andras Timar 2011-03-06 13:13:02 UTC
I created a work-around for this bug which is a pre-generated SDF file of the fallback strings. I opened a new bug 35067 for the real fix in l10ntools.
Comment 16 Nodens 2011-03-07 12:13:39 UTC
I don't understand, where is the fix for the end-users?
Comment 17 Andras Timar 2011-03-08 05:00:21 UTC
(In reply to comment #16)
> I don't understand, where is the fix for the end-users?

http://cgit.freedesktop.org/libreoffice/build/commit/?h=libreoffice-3-3&id=64167296e8821a045c77250776ba6aee8c2f8ef7

I generated all missing fallback lines in a huge SDF file and it is applied during the build.
Comment 18 Andras Timar 2011-03-08 05:03:14 UTC
I mean end-users will have the fix with LibreOffice 3.3.2.
Comment 19 Nodens 2011-03-08 09:43:11 UTC
A! OK then! Is there any ETA for version 3.3.2 (even Beta or RC)?