Bug 413390 - Date in 'Help/About KDevelop' shows year "2.019" instead of "2019"
Summary: Date in 'Help/About KDevelop' shows year "2.019" instead of "2019"
Status: RESOLVED FIXED
Alias: None
Product: kdevelop
Classification: Applications
Component: UI: general (show other bugs)
Version: unspecified
Platform: Appimage Linux
: NOR minor
Target Milestone: ---
Assignee: kdevelop-bugs-null
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2019-10-24 12:29 UTC by Wolf Behrenhoff
Modified: 2019-11-01 19:15 UTC (History)
6 users (show)

See Also:
Latest Commit:
Version Fixed In: 5.4.4


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Wolf Behrenhoff 2019-10-24 12:29:42 UTC
SUMMARY

Go to "Help/About KDevelop" in the menu (since I am using a German locale, it is "Hilfe/Über KDevelop" here). The text shown reads:

  "Copyright 1999-2.019, The KDevelop developers"

The year 2019 should not be formatted with a thousands separator.
Could it be the second year is formatted as an int with German locale? If using a locale for the year is really required, it should be formatted as a year, not as a number.


SOFTWARE/OS VERSIONS

I am using the x86_64 AppImage version 5.4.3 (not in list of available version, so I selected "unspecified")

Linux/KDE Plasma: 
Kubuntu 18.04 LTS
KDE Frameworks 5.63.0
Qt 5.12.4 (kompiliert gegen 5.12.4)
Comment 1 Francis Herne 2019-10-24 12:42:28 UTC
Confirmed. Also happens in English, with "2,019".

This is due to a breaking change in v5.62 of the ki18n library:

https://phabricator.kde.org/D22069
Comment 2 Nate Graham 2019-10-24 13:46:22 UTC
Do we have a way to mark a number as being a year or something? That could trigger logic to say, "Don't localize this number!"
Comment 3 Francis Herne 2019-10-24 13:52:27 UTC
I don't know. Did you add one when you added the behaviour?

(Not that I can find)
Comment 4 Karl Ove Hufthammer 2019-10-24 16:39:14 UTC
(In reply to Nate Graham from comment #2)
> Do we have a way to mark a number as being a year or something? That could
> trigger logic to say, "Don't localize this number!"

Yes. See https://techbase.kde.org/Development/Tutorials/Localization/i18n_Semantics

The relevant quote is:

<numid>
By default, numbers supplied as arguments to i18n calls are formatted into localized form. If the number is supposed to be a numeric identifier instead, like a port number, use this tag to signal numeric-id environment.
i18nc("@info:progress",
      "Connecting to <numid>%1</numid>...", portNo);
Comment 5 Friedrich W. H. Kossebau 2019-10-24 16:46:22 UTC
(In reply to Karl Ove Hufthammer from comment #4)
> (In reply to Nate Graham from comment #2)
> > Do we have a way to mark a number as being a year or something? That could
> > trigger logic to say, "Don't localize this number!"
> 
> Yes. See
> https://techbase.kde.org/Development/Tutorials/Localization/i18n_Semantics
> 
> The relevant quote is:
> 
> <numid>
> By default, numbers supplied as arguments to i18n calls are formatted into
> localized form. If the number is supposed to be a numeric identifier
> instead, like a port number, use this tag to signal numeric-id environment.
> i18nc("@info:progress",
>       "Connecting to <numid>%1</numid>...", portNo);

Nope. this is pre-KF5 information. That page should get a note saying so.

When using semantic markup (KDE User Interface Text = KUIT), one needs to use the xi18n call variants with KF5's KI18n API.
See https://api.kde.org/frameworks/ki18n/html/prg_guide.html#kuit_markup

It might be more simple though to just format the year as string using the respective QLocale date string methods and then pass this string as arg.
Comment 6 Karl Ove Hufthammer 2019-10-24 17:47:00 UTC
> When using semantic markup (KDE User Interface Text = KUIT), one needs to
> use the xi18n call variants with KF5's KI18n API.
> See https://api.kde.org/frameworks/ki18n/html/prg_guide.html#kuit_markup
> 
> It might be more simple though to just format the year as string using the
> respective QLocale date string methods and then pass this string as arg.

According to that page, one should just use QString::number(year).
And that seems simple enough.
Comment 7 Friedrich W. H. Kossebau 2019-10-28 19:54:49 UTC
QString::number(year) will not be localized though (and we could simply already use the result, QStringLiteral("2019") instead :)

To get a string of a year (without just delegating to translators, as the whole idea of this is to avoid breaking string freeze on change of year e.g. in stable branch, one could perhaps do this, though this relies on Gregorian calendar again, given we have to specify a day when using QDate:
--- 8< ---
    const QString copyrightYearEnd = QLocale().toString(QDate(2019, 1, 1), QStringLiteral("yyyy"));
    KAboutData aboutData( QStringLiteral("kdevelop"), i18n("KDevelop"), QStringLiteral(KDEVELOP_VERSION_STRING),
                          i18n("The KDevelop Integrated Development Environment"),
                          KAboutLicense::GPL, i18n("Copyright 1999-%1, The KDevelop developers", copyrightYearEnd),
                          QString(), QStringLiteral("https://www.kdevelop.org/"));
--- 8< ---

Going to ask on the kde-i18n-doc@kde.org mailinglist what they suggest to do.
Comment 8 Albert Astals Cid 2019-10-28 22:17:00 UTC
QLocale::toString
Returns a localized string representation of i.

That is not what you want.
Comment 9 Albert Astals Cid 2019-10-28 22:17:51 UTC
(In reply to Albert Astals Cid from comment #8)
> QLocale::toString
> Returns a localized string representation of i.
> 
> That is not what you want.

Ah sorry i didn't realize you where passing in a date.

Why is this all so convoluted instead of just hardcoding a 2019 there?
Comment 10 Friedrich W. H. Kossebau 2019-11-01 19:15:14 UTC
Git commit 748ec8549f99893c29169c7603a16990ddc6cfa0 by Friedrich W. H. Kossebau.
Committed on 01/11/2019 at 19:14.
Pushed by kossebau into branch '5.4'.

Fix copyright date display in About KDevelop/KDevPlatform dialogs

Passing in a plain int gets localized integer text rendering with
e.g. thousand separator (2.019), which is not what we want here.

By feedback of localization teams the original year span is used, and
not mapped into local calendar systems at least by the active teams,
so just passing in a plain string is fine for now.
Cmp. https://marc.info/?l=kde-i18n-doc&m=157238863619132&w=2
FIXED-IN:5.4.4

M  +2    -1    app/main.cpp
M  +2    -1    kdevplatform/shell/core.cpp

https://invent.kde.org/kde/kdevelop/commit/748ec8549f99893c29169c7603a16990ddc6cfa0