Created attachment 22166 [details]
calendar in agenda wizard

reassigned.

Interesting thing is that in German version, it is correct.

rpiterman: can you help here?

TV->pjanik: I tested it with English, German and French -> All ok. In which
language do you have problems? Maybe there is only support for the Sun big 10
languages..

.

TV: In case it does not work for languages other than Big10 you shoul contact
Eike Rathke (er@openoffice.org).

It doesn't work for czech language. Locale code cs_CZ. You will see English
names of months and week should start here with Monday.

I have looked on it, the control element comes from Sun's awt library, but I am
not able locate, where exactly is defined, or if there is source from this in
OOo tarball at all.

reopening.
Still does not work for Czech.
ain: what is the status for Estonian?
er: can you help danohnesorg to fix this issue also for non-Sun languages, please?

tv: we can't find a person responsible for awt locale implementation inside OOo.

Can you please reassign to him/her or at least tell us who can help us to solve
this?

Thank you.

In Brazilian Portuguese (1.9.74) there is no problem.

TV->ER: The agenda wizard is using a com.sun.star.awt.XDateField
This should support also locales other than the Sun Big10.

Malte,

From a first glance, implementation seems to be in the toolkit module.
Unfortunately the files don't have an owner set, please reassign this issue to
the proper developer who is in charge now.

Thanks
Eike

MT->FS: Not sure - you or SSA?

This is known as internal issue 109073 - I will close the latter as a duplicate
of this one.

Unfortunately, I once inherited this bug from SSA, because form controls where
the only clients of the particular VCL control.

citing from 109073:
<cite>
SSA->FS: The problem is that the calendar control
(svtools/source/control/calendar.cxx) still uses the deprecated International
class from tools, which only supports a few languages. Greek and Turkish are not
supported, thus only english months are displayed.
According to ER the calendar control should use the LocaleDataWrapper from
unotools which provides ver similar function names, so it should not be that
much effort...

FS: I am not reall happy with the ownership of this control (which we by
accident use in forms :). More precisely, I refuse to have the ownership for
this control :), but I think I could fix this bug here, anyway.

MSC:
"According to the OpenOffice.org roadmap (http://tools.openoffice.org/releases)
this issue was retargeted to OOo Later."
</cite>

As a consequence, I target this one here to Later, too. Sorry, but we're too
late in the schedule to accept issues whose fixes are that bad to judge in their
consequences ...

Huh, this is really ugly tools/source/intntl/intntab.cxx:

// Februar
  
static char const aFebruary[]             = "February";   
static char const aFebruar[]              = "Februar";
static char const afebruar[]              = "februar";
static char const afebruari[]             = "februari";
static char const afeACvrier[]            = "f" EAC "vrier";
static char const afebbraio[]             = "febbraio";
static char const afebrero[]              = "febrero";
static char const afevereiro[]            = "fevereiro";
static char const ahelmikuu[]             = "helmikuu";

Uff :-(

There is only needed replace this function for day names and other for months names.

                // DayOffWeekText berechnen (werden im schmalen Font ausgegeben)
                maDayOfWeekText.Erase();
                long nStartOffX = 0;
                USHORT eDay = (USHORT)eStartDay;
                for ( USHORT nDayOfWeek = 0; nDayOfWeek < 7; nDayOfWeek++ )
                {
                        String aDayOfWeek( maIntn.GetAbbrevDayText(
(DayOfWeek)eDay ).GetChar( 0 ) );
                        long nOffX = (mnDayWidth-GetTextWidth( aDayOfWeek ))/2;
                        if ( mnWinStyle & WB_BOLDTEXT )
                                nOffX++;
                        if ( !nDayOfWeek )
                                nStartOffX = nOffX;
                        else
                                nOffX -= nStartOffX;
                        nOffX += nDayOfWeek * mnDayWidth;
                        mnDayOfWeekAry[nDayOfWeek] = nOffX;
                        maDayOfWeekText += aDayOfWeek;
                        eDay++;
                        eDay %= 7;
                }

Dan: i do not think so. Have a look for all lines using maIntn:

- maIntn.GetWeekStart
- maIntn.GetAbbrevDayText
- maIntn.GetMonthText
- maIntn.GetAbbrevMonthText
- maIntn.GetWeekCountStart

Dan, if you want to submit a patch, I'll gladly review it.
(And no, I will *not* tag your name onto the owner-label of the file then  :)

Seems be not to hard to change.

Eike: Will be a patch against unsuported and oudated component accepted? At
least Czech and Slovak localization needs this, I don't know how other
localizations are working on templates.

OK I will prepare in the evening patch, Pavel will make a test build over night
and if it works, i will submit the patch.

Dan,

A simple patch against that deprecated code should be acccepted in this case.
However, instead of simply extending the class International respectively its
use I strongly suggest to use the LocaleDataWrapper from the unotools module
instead. Doing so would fix this for all supported locales. But then again it
must be taken care that the locale's calendar is a Gregorian calendar, or
measurements be taken if it isn't and fall back to an en_US calendar. Otherwise
the code wouldn't work as is.

Instead of initializing
maIntn( Application::GetAppInternational() )
it would be
mrLocaleData( Application::GetSettings().GetLocaleDataWrapper())
with mrLocaleData being a const LocaleDataWrapper &

Eike

BC: I will remove this issue from cws toolkit01 because not yet fixed

I have made a patch, but the UI is still in English, probably the eLanguange is
not set into CZECH somewhere, but I dont see where

Created attachment 23244 [details]
Czech locales for old locales library

Dan,

Please modify the patch such that no 8bit characters are used, use escape
sequences instead, like \xAB. This because some compiler is a bit weird in
processing 8bit characters, see issue 36782 ...

Thanks
Eike

I have remade the patch and broaded them, becouse I have found, that I must also
patch files tools/inc/intntab.hxx and tools/source/intntl/intn.cxx too, to get
it working.

Patch will be tested in czech builds starting with m97.

Hi, I'm doing the same patch for Bulgarian. I use 1251 encoding for our language
in these files. Do I ahve to use escape sequences for every letter?

Hi Hristo,

Not for every character, just make sure you escape characters that are not plain
ASCII (== have the 8th bit set).

Thanks
  Eike

If I undestand this correctly. In this file have to be used 7-bit ASCII table.
But Cyrillic characters are above 127 code. So, I have to use escape sequences
for every letter.

Grabbing issue, this is related to issue 50205.

Accepted, assigned to CWS internatiodel.

On branch cws_src680_internatiodel:
svtools/inc/calendar.hxx 1.3.60.1
svtools/source/control/calendar.cxx 1.5.146.1

Reassigning to QA.

re-open issue and reassign to oc@openoffice.org

reassign to oc@openoffice.org

reset resolution to FIXED

Retargeting to OOo3.0

Retargeting to OOo2.0.3.

verified in internal build cws_internatiodel

closed because fix available in OpenOffice.org Developer Snapshot Build src680_m167