> On June 1, 2014, 5:22 p.m., Alexander Potashev wrote: > > What is the user changes the locale at run-time - will the query parser > > reload the month/weekday names? > > Denis Steckelmacher wrote: > It depends on the client application. This list is cached in > pass_periodnames, that is private to one Baloo::QueryParser instance. If the > application, let's say KRunner, instantiates a new parser for every query, > then the new calendar will be used as soon as the user changes it. > > Alexander Potashev wrote: > OK. I guess adding some notification/listening API of KCalendarSystem in > order to pull the changes in the current locale automatically would be an > overkill. May be this name caching should be told about in a comment in code. > > John Layt wrote: > The Locale KCM does signal out when it changes teh locale, you may be > able to listen for that: > > KGlobalSettings::self()->emitChange(KGlobalSettings::SettingsChanged, > KGlobalSettings::SETTINGS_LOCALE); > > Note that this, like KCalendarSystem itself, is KDE4 only: in KF5 we > switch to using QLocale, and I haven't yet got calendar system support merged > into Qt. > > Denis Steckelmacher wrote: > Hummm, how will this problem be solved in KF5 then? The Baloo query > parser is supposed to make it first apparition in KF5, so it has to work well > there. Do you think that, as a temporary workaround, the query parser should > provide the month and day names itself (a bit like what was done before this > patch, but with the ability to decouple calendar systems from languages)?
Baloo should not localise them itself, it should always use the locale via KLocale or QLocale, that's what they are there for. In KDE4 it must be via KLocale/KCalendarSystem, in KF5 via QLocale. The KF5 Porting Aid library kdelibs4support still has KCalendarSystem, but that's only supported for 3 releases. I plan to have QCalendarSystem in Qt 5.4 or 5.5, so before kdelibs4support gets dropped. Even if I don't, QLocale already has dayName() and monthName() methods that will give you the current names. - John ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/118448/#review58904 ----------------------------------------------------------- On June 1, 2014, 12:54 p.m., Denis Steckelmacher wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > https://git.reviewboard.kde.org/r/118448/ > ----------------------------------------------------------- > > (Updated June 1, 2014, 12:54 p.m.) > > > Review request for Baloo, Localization and Translation (l10n) and Alexander > Potashev. > > > Repository: baloo > > > Description > ------- > > The query parser made the erroneous assumption that each language uses at > most one calendar system, and therefore used i18nc to translate the month and > day names recognized by the parser. This patches changes that and uses the > KCalendarSystem of the user to get the month and day names. > > I've written the code by looking at how the gregorian, hebrew and islamic > calendars work (these are the three that I somehow understand). The idea is > to try to get as many days and months as possible, by incrementing an index > until the calendar system returns NULL strings. This works well for days, but > monthName() requires a year, that is used by some calendar systems to > rename/add months on leap years. I pass the current year, as most of the > users will look for dates not too far in the future nor in the past. Is there > a mean to get the complete list of month names and their corresponding > number, using KCalendarSystem or anything else? > > > Diffs > ----- > > src/queryparser/pass_periodnames.h 1d7d522 > src/queryparser/pass_periodnames.cpp da688ed > > Diff: https://git.reviewboard.kde.org/r/118448/diff/ > > > Testing > ------- > > The query parser testsuite still passes, and properly gets the name of > Gregorian months and days (the tests run using the C locale). > > > Thanks, > > Denis Steckelmacher > >
>> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe <<
