Created attachment 42104 [details]
Screenshot describing the problem

Title is "Range and copies" but there is no range input field.

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

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

Created attachment 43099 [details]
Screenshot of the same system, same file and same LO version with C locale

L10n bug, I take it.

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.

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?

> 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.

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

It looks like a regression of http://www.openoffice.org/issues/show_bug.cgi?id=74982 or something similar.

*** Bug 33865 has been marked as a duplicate of this bug. ***

*** Bug 34343 has been marked as a duplicate of this bug. ***

*** Bug 33764 has been marked as a duplicate of this bug. ***

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).

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.

I don't understand, where is the fix for the end-users?

(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.

I mean end-users will have the fix with LibreOffice 3.3.2.

A! OK then! Is there any ETA for version 3.3.2 (even Beta or RC)?