D10446: Add KLanguageName

[Harald Sitter]

sitter added a comment.


  Oh actually. I have a theory. My environment vars were wrong. Try with 
s/LANG/LANGUAGE and s/LOCALE/LANG please.

REPOSITORY
  R265 KConfigWidgets

REVISION DETAIL
  https://phabricator.kde.org/D10446

To: aacid, apol
Cc: rikmills, vkrause, dhaumann, hein, kde-frameworks-devel, sitter, markg, 
apol, michaelh, ngraham, bruns

D10446: Add KLanguageName

[Harald Sitter]

sitter added a comment.


  You'll have to debug this for us. It passes on build.kde.org 

REPOSITORY
  R265 KConfigWidgets

REVISION DETAIL
  https://phabricator.kde.org/D10446

To: aacid, apol
Cc: rikmills, vkrause, dhaumann, hein, kde-frameworks-devel, sitter, markg, 
apol, michaelh, ngraham, bruns

D10446: Add KLanguageName

[Rik Mills]

rikmills added a comment.


  Kubuntu CI builds
  
  2/4 Test #3: klanguagenametest ***Failed0.03 sec
  
  - Start testing of KLanguageNameTest *
  
  Config: Using QtTest library 5.11.3, Qt 5.11.3 (x86_64-little_endian-lp64 
shared (dynamic) release build; by GCC 8.2.0)
  PASS   : KLanguageNameTest::initTestCase()
  FAIL!  : KLanguageNameTest::testNameForCode() Compared values are not the same
  
Actual   (KLanguageName::nameForCode("en")): "English"
Expected ("US English"): US English
Loc: 
[/<>/kconfigwidgets-5.54.0+p19.04+git20190111.0330/autotests/klanguagenametest.cpp(46)]
  
  PASS   : KLanguageNameTest::testNameForCodeInLocale()
  PASS   : KLanguageNameTest::testNoTranslation()
  PASS   : KLanguageNameTest::testNoEntry()
  PASS   : KLanguageNameTest::testNoString()
  PASS   : KLanguageNameTest::cleanupTestCase()
  Totals: 6 passed, 1 failed, 0 skipped, 0 blacklisted, 6ms
  
  - Finished testing of KLanguageNameTest *

REPOSITORY
  R265 KConfigWidgets

REVISION DETAIL
  https://phabricator.kde.org/D10446

To: aacid, apol
Cc: rikmills, vkrause, dhaumann, hein, kde-frameworks-devel, sitter, markg, 
apol, michaelh, ngraham, bruns

D10446: Add KLanguageName

[Dominik Haumann]

dhaumann added a comment.


  I don't think you'd have to import .desktop files. But you would need some 
lookup table of course to map the names.

REPOSITORY
  R265 KConfigWidgets

REVISION DETAIL
  https://phabricator.kde.org/D10446

To: aacid, apol
Cc: vkrause, dhaumann, hein, kde-frameworks-devel, sitter, markg, apol, 
michaelh, ngraham, bruns

D10446: Add KLanguageName

[Volker Krause]

vkrause added a comment.


  In D10446#390025 , @aacid wrote:
  
  > In D10446#389972 , @dhaumann 
wrote:
  >
  > > Btw, wouldn't this be a good candidate to upstream to Qt itself?
  >
  >
  > You'd have to import all our .desktop files containing all the translations 
of all languages to all langauges. Impossible copyright wise
  
  
  Getting slightly off-topic here, but CLDR has those translations too, in case 
someone really would want to add this feature to Qt. That's where most other 
data inside QLocale is coming from too.

REPOSITORY
  R265 KConfigWidgets

REVISION DETAIL
  https://phabricator.kde.org/D10446

To: aacid, apol
Cc: vkrause, dhaumann, hein, kde-frameworks-devel, sitter, markg, apol, 
michaelh, ngraham, bruns

D10446: Add KLanguageName

[Albert Astals Cid]

aacid added a comment.


  In D10446#389972 , @dhaumann wrote:
  
  > Btw, wouldn't this be a good candidate to upstream to Qt itself?
  
  
  You'd have to import all our .desktop files containing all the translations 
of all languages to all langauges. Impossible copyright wise

REPOSITORY
  R265 KConfigWidgets

REVISION DETAIL
  https://phabricator.kde.org/D10446

To: aacid, apol
Cc: dhaumann, hein, kde-frameworks-devel, sitter, markg, apol, michaelh, 
ngraham, bruns

D10446: Add KLanguageName

[Dominik Haumann]

dhaumann added a comment.


  Btw, wouldn't this be a good candidate to upstream to Qt itself?

REPOSITORY
  R265 KConfigWidgets

REVISION DETAIL
  https://phabricator.kde.org/D10446

To: aacid, apol
Cc: dhaumann, hein, kde-frameworks-devel, sitter, markg, apol, michaelh, 
ngraham, bruns

D10446: Add KLanguageName

[Harald Sitter]

This revision was automatically updated to reflect the committed changes.
Closed by commit R265:91077def022a: Add KLanguageName (authored by aacid, 
committed by sitter).

CHANGED PRIOR TO COMMIT
  https://phabricator.kde.org/D10446?vs=48854=49079#toc

REPOSITORY
  R265 KConfigWidgets

CHANGES SINCE LAST UPDATE
  https://phabricator.kde.org/D10446?vs=48854=49079

REVISION DETAIL
  https://phabricator.kde.org/D10446

AFFECTED FILES
  autotests/CMakeLists.txt
  autotests/kf5_entry_data.cmake/locale/ca/kf5_entry.cmake
  autotests/kf5_entry_data.cmake/locale/de/kf5_entry.cmake
  autotests/kf5_entry_data.cmake/locale/en_US/kf5_entry.cmake
  autotests/kf5_entry_data.cmake/locale/es/.keep
  autotests/kf5_entry_data.cmake/locale/fr/kf5_entry.cmake
  autotests/kf5_entry_data.cmake/locale/pt/kf5_entry.cmake
  autotests/klanguagenametest.cpp
  src/CMakeLists.txt
  src/klanguagename.cpp
  src/klanguagename.h

To: aacid, apol
Cc: hein, kde-frameworks-devel, sitter, markg, apol, michaelh, ngraham, bruns

D10446: Add KLanguageName

[Harald Sitter]

sitter added inline comments.

INLINE COMMENTS

> aacid wrote in klanguagenametest.cpp:80
> Do you think it makes sense adding this?
> 
>   void testNoString()
>   {
>   // Qt doesn't have za support so no string at all
>   QCOMPARE(KLanguageName::nameForCode("za"), QString());
>   }

 I'll add it

> aacid wrote in klanguagename.h:34
> Needs to be 5.55 i think

Going to update

REPOSITORY
  R265 KConfigWidgets

BRANCH
  arcpatch-D10446

REVISION DETAIL
  https://phabricator.kde.org/D10446

To: aacid, apol
Cc: hein, kde-frameworks-devel, sitter, markg, apol, michaelh, ngraham, bruns

D10446: Add KLanguageName

[Aleix Pol Gonzalez]

apol accepted this revision.
This revision is now accepted and ready to land.

REPOSITORY
  R265 KConfigWidgets

BRANCH
  arcpatch-D10446

REVISION DETAIL
  https://phabricator.kde.org/D10446

To: aacid, apol
Cc: hein, kde-frameworks-devel, sitter, markg, apol, michaelh, ngraham, bruns

D10446: Add KLanguageName

[Albert Astals Cid]

aacid added a comment.


  Two more small comments from my side, otherwise looks cool :) Thanks for the 
perseverance!
  
  I can't approve it because the review is on my name ^_^
  
  Maybe @apol can give it the ship it?

INLINE COMMENTS

> klanguagenametest.cpp:80
> +}
> +};
> +

Do you think it makes sense adding this?

  void testNoString()
  {
  // Qt doesn't have za support so no string at all
  QCOMPARE(KLanguageName::nameForCode("za"), QString());
  }

> sitter wrote in klanguagename.cpp:30
> Do you mean both being **a** code or both being **the** code?
> 
> a code
> ==
> 
> `parts.at(0)` is the code of the current locale. The only way I found to get 
> the 639 code from qlocale is by splitting name 
> http://doc.qt.io/qt-5/qlocale.html#name
> 
> Perhaps a comment is needed to explain this?
> 
> the code
> 
> 
> Both params being the variable `code` wouldn't be right I think. The 
> documentation for `nameForCode` says it will ideally give you the localized 
> name of code in the system language.
> 
>   LANGUAGE=en nameForCode('en') => 'English'
>   LANGUAGE=fr nameForCode('en') => 'anglaise'
> 
> which internally is
> 
>   nameForCodeInLocale('en', 'en')
>   nameForCodeInLocale('en', 'fr')

Ar, ignore me i was reading the code wrong. Sorry for the noise

> klanguagename.h:34
> + *
> + * @since 5.44
> + *

Needs to be 5.55 i think

REPOSITORY
  R265 KConfigWidgets

REVISION DETAIL
  https://phabricator.kde.org/D10446

To: aacid
Cc: hein, kde-frameworks-devel, sitter, markg, apol, michaelh, ngraham, bruns

D10446: Add KLanguageName

[Harald Sitter]

sitter added inline comments.

INLINE COMMENTS

> aacid wrote in klanguagename.cpp:30
> should the second param be code too?
> 
> I mean if we read the docs we say both are code (ISO 639-1), so both should 
> be the same and not only the first part?

Do you mean both being **a** code or both being **the** code?

a code
==

`parts.at(0)` is the code of the current locale. The only way I found to get 
the 639 code from qlocale is by splitting name 
http://doc.qt.io/qt-5/qlocale.html#name

Perhaps a comment is needed to explain this?

the code


Both params being the variable `code` wouldn't be right I think. The 
documentation for `nameForCode` says it will ideally give you the localized 
name of code in the system language.

  LANGUAGE=en nameForCode('en') => 'English'
  LANGUAGE=fr nameForCode('en') => 'anglaise'

which internally is

  nameForCodeInLocale('en', 'en')
  nameForCodeInLocale('en', 'fr')

REPOSITORY
  R265 KConfigWidgets

REVISION DETAIL
  https://phabricator.kde.org/D10446

To: aacid
Cc: hein, kde-frameworks-devel, sitter, markg, apol, michaelh, ngraham, bruns

D10446: Add KLanguageName

[Albert Astals Cid]

aacid added inline comments.

INLINE COMMENTS

> klanguagename.cpp:30
> +const QStringList parts = QLocale().name().split(QChar('_'));
> +return nameForCodeInLocale(code, parts.at(0));
> +}

should the second param be code too?

I mean if we read the docs we say both are code (ISO 639-1), so both should be 
the same and not only the first part?

REPOSITORY
  R265 KConfigWidgets

REVISION DETAIL
  https://phabricator.kde.org/D10446

To: aacid
Cc: hein, kde-frameworks-devel, sitter, markg, apol, michaelh, ngraham, bruns

D10446: Add KLanguageName

[Harald Sitter]

sitter updated this revision to Diff 48853.
sitter added a comment.


  configure_file the fixtures lest they get mangled by scripty on account of 
being desktop files
  
  lookup still goes through qfindtestdata, so we need the output relative to
  the binary now

REPOSITORY
  R265 KConfigWidgets

CHANGES SINCE LAST UPDATE
  https://phabricator.kde.org/D10446?vs=47758=48853

BRANCH
  arcpatch-D10446

REVISION DETAIL
  https://phabricator.kde.org/D10446

AFFECTED FILES
  autotests/CMakeLists.txt
  autotests/kf5_entry_data.cmake/locale/ca/kf5_entry.cmake
  autotests/kf5_entry_data.cmake/locale/de/kf5_entry.cmake
  autotests/kf5_entry_data.cmake/locale/en_US/kf5_entry.cmake
  autotests/kf5_entry_data.cmake/locale/fr/kf5_entry.cmake
  autotests/kf5_entry_data.cmake/locale/pt/kf5_entry.cmake
  autotests/klanguagenametest.cpp
  src/CMakeLists.txt
  src/klanguagename.cpp
  src/klanguagename.h

To: aacid
Cc: hein, kde-frameworks-devel, sitter, markg, apol, michaelh, ngraham, bruns

D10446: Add KLanguageName

[Harald Sitter]

sitter added inline comments.

INLINE COMMENTS

> aacid wrote in kf5_entry.desktop:1
> If you look carefully at Messages.sh, you'll see that they never mention 
> .desktop files, that's because .desktop files are extracted automatically for 
> translation, so yes, it will be a problem, because translations will be 
> dropped (until translators translate them), making the test flaky

Ah, you are absolutely right.

In this case I agree configure_file is the way to go. I'll get on it tomorrow.

REPOSITORY
  R265 KConfigWidgets

REVISION DETAIL
  https://phabricator.kde.org/D10446

To: aacid
Cc: hein, kde-frameworks-devel, sitter, markg, apol, michaelh, ngraham, bruns

D10446: Add KLanguageName

[Albert Astals Cid]

aacid added inline comments.

INLINE COMMENTS

> sitter wrote in kf5_entry.desktop:1
> Really good point. I've had a look and we only extract src/*. In fact, we 
> only have Messages.sh in src :)
> 
> This is in line with other frameworks where we have desktop file fixtures. 
> They all only extract src/ and use regular desktop files for test fixtures 
> (e.g. kservice, kpackage, kparts). So, this should be fine.

If you look carefully at Messages.sh, you'll see that they never mention 
.desktop files, that's because .desktop files are extracted automatically for 
translation, so yes, it will be a problem, because translations will be dropped 
(until translators translate them), making the test flaky

REPOSITORY
  R265 KConfigWidgets

REVISION DETAIL
  https://phabricator.kde.org/D10446

To: aacid
Cc: hein, kde-frameworks-devel, sitter, markg, apol, michaelh, ngraham, bruns

D10446: Add KLanguageName

[Harald Sitter]

sitter added inline comments.

INLINE COMMENTS

> aacid wrote in kf5_entry.desktop:1
> This is going to be a problem, scripty is going to come and whipe these 
> .desktop files out and then make the translators translate them again.
> 
> Wonder if we could rename them to .desktop.untransltable or something like 
> that and then use the cmake file copy command to copy them to the build 
> folder and trick the test to find the files there?
> 
> Am i making any sense?

Really good point. I've had a look and we only extract src/*. In fact, we only 
have Messages.sh in src :)

This is in line with other frameworks where we have desktop file fixtures. They 
all only extract src/ and use regular desktop files for test fixtures (e.g. 
kservice, kpackage, kparts). So, this should be fine.

> aacid wrote in klanguagenametest.cpp:32
> initTestCase is too late and was failing for me
> 
> https://paste.kde.org/p8s9js4r3
> 
> makes it work

LGTM, I've added the change to the diff. Thanks.

REPOSITORY
  R265 KConfigWidgets

REVISION DETAIL
  https://phabricator.kde.org/D10446

To: aacid
Cc: hein, kde-frameworks-devel, sitter, markg, apol, michaelh, ngraham, bruns

D10446: Add KLanguageName

[Harald Sitter]

sitter updated this revision to Diff 47758.
sitter added a comment.


  move env setup to qcorestartup to prevent the env from not getting set up in 
time and the tests failing as a result

REPOSITORY
  R265 KConfigWidgets

CHANGES SINCE LAST UPDATE
  https://phabricator.kde.org/D10446?vs=47623=47758

BRANCH
  arcpatch-D10446

REVISION DETAIL
  https://phabricator.kde.org/D10446

AFFECTED FILES
  autotests/CMakeLists.txt
  autotests/kf5_entry_data/locale/ca/kf5_entry.desktop
  autotests/kf5_entry_data/locale/de/kf5_entry.desktop
  autotests/kf5_entry_data/locale/en_US/kf5_entry.desktop
  autotests/kf5_entry_data/locale/fr/kf5_entry.desktop
  autotests/kf5_entry_data/locale/pt/kf5_entry.desktop
  autotests/klanguagenametest.cpp
  src/CMakeLists.txt
  src/klanguagename.cpp
  src/klanguagename.h

To: aacid
Cc: hein, kde-frameworks-devel, sitter, markg, apol, michaelh, ngraham, bruns

D10446: Add KLanguageName

[Albert Astals Cid]

aacid added inline comments.

INLINE COMMENTS

> kf5_entry.desktop:1
> +[KCM Locale]
> +Name=Catalan

This is going to be a problem, scripty is going to come and whipe these 
.desktop files out and then make the translators translate them again.

Wonder if we could rename them to .desktop.untransltable or something like that 
and then use the cmake file copy command to copy them to the build folder and 
trick the test to find the files there?

Am i making any sense?

> klanguagenametest.cpp:32
> +void initTestCase()
> +{
> +qputenv("LOCALE", "C.UTF-8");

initTestCase is too late and was failing for me

https://paste.kde.org/p8s9js4r3

makes it work

REPOSITORY
  R265 KConfigWidgets

REVISION DETAIL
  https://phabricator.kde.org/D10446

To: aacid
Cc: hein, kde-frameworks-devel, sitter, markg, apol, michaelh, ngraham, bruns

D10446: Add KLanguageName

[Harald Sitter]

sitter added a comment.


  In D10446#377355 , @aacid wrote:
  
  > But you end up repeating that in lots of places (which we should there's 
lots of places that suffer from trying to guess a language name at this point, 
and all of them went the bad way one way or another). If you want to give some 
random potential user more flexibility i'm fine with that, add some flags, but 
i want the "give me the best you can do" possibility to still work. Maybe we 
should even never return an empty string and worst case scenario return code 
back.
  
  
  I am not too invested in the use case. For all I care we can leave it as it 
is and should the no-fallback usecase actually get requested we can simply add 
a three-argument variant of the function without default value for KF5 and 
reshuffle the functions for KF6.
  
  The diff as it is right now is good IMO

REPOSITORY
  R265 KConfigWidgets

REVISION DETAIL
  https://phabricator.kde.org/D10446

To: aacid
Cc: hein, kde-frameworks-devel, sitter, markg, apol, michaelh, ngraham, bruns

D10446: Add KLanguageName

[Harald Sitter]

sitter updated this revision to Diff 47623.
sitter added a subscriber: hein.
sitter added a comment.


  iterating the diff a bit as mentioned in a comment.
  
  - new unit test which covers all likely scenarios (I think). this uses 
fixtures and doesn't require anything to be installed etc.
  - the specific func now calls the generic to resolve into current-language. 
this requires some string mangling as qlocale apparently has no way to get the 
ISO639-1 string directly
  - some refinement on the english-check resolution: now returns the kconfig 
resolved name iff it is different from english and it is not english 
(previously this was a bit bugged for english itself)
  - some refinement on the qlocale fallback: now returns immediately when a 
final result is found (simplifies code a bit)
  - a failed kconfig resolution (for whatever reason) now always continues 
onwards into the qlocale fallback. this effectively separates the kconfig 
portion entirely from the qlocale portion for ease of reading
  
  as mentioned in an earlier comment I am not too sure about giving out 
languageToString names and would rather have it always give out 
nativeLanguageNames. I am somewhat indifferent on the issue though, it's just a 
gut feeling is all.
  
  I should also note that I had a quick look at systemsettings and it also does 
exhaustive poking of QLocale to come up with reasonable prettynames for locales 
(and then fails in part). Perhaps @hein could take a look at this diff and see 
if it could be useful for the language KCM and/or give some thoughts on what 
may be needed to make that happen. For the record though: since KLanguageName 
exclusively deals with languages and the KCM AFAIK deals with locales there is 
no 100% overlap; perhaps there should be though.

REPOSITORY
  R265 KConfigWidgets

CHANGES SINCE LAST UPDATE
  https://phabricator.kde.org/D10446?vs=26943=47623

BRANCH
  arcpatch-D10446

REVISION DETAIL
  https://phabricator.kde.org/D10446

AFFECTED FILES
  autotests/CMakeLists.txt
  autotests/kf5_entry_data/locale/ca/kf5_entry.desktop
  autotests/kf5_entry_data/locale/de/kf5_entry.desktop
  autotests/kf5_entry_data/locale/en_US/kf5_entry.desktop
  autotests/kf5_entry_data/locale/fr/kf5_entry.desktop
  autotests/kf5_entry_data/locale/pt/kf5_entry.desktop
  autotests/klanguagenametest.cpp
  src/CMakeLists.txt
  src/klanguagename.cpp
  src/klanguagename.h

To: aacid
Cc: hein, kde-frameworks-devel, sitter, markg, apol, michaelh, ngraham, bruns

D10446: Add KLanguageName

[Albert Astals Cid]

aacid added a comment.


  In D10446#376825 , @sitter wrote:
  
  > Stacking the functions seems to work fine
  >
  >   QString KLanguageName::nameForCode(const QString )
  >   {
  >   const QStringList parts = QLocale().name().split(QChar('_'));
  >   return nameForCodeInLocale(code, parts.at(0));
  >   }
  >
  >
  > I do have various refinements and fixes for the logic plus a unit test I 
can update the diff if you are ok with that.
  
  
  Sure, tests are nice i remember this was kind of a bit of a hit and miss 
sometimes. But are you going to depend on having all of l10n installed (which 
is where kf5_entry.desktop files come from or will you have some fake 
kf5_entry.destkops for the test? (second would be awesome)
  
  > As for kcoreaddons, I don't think we could go there with kconfig could we? 
And I am not sure QSettings is up to the task?
  
  QSettings doesn't support language entries AFAIK
  
  > I also have some behavior concerns. The auto-fallback to QLocale is super 
handy, but isn't very flexible: As an application author I might have another 
way to map a language to a pretty string, if KLanguageName automatically falls 
back to QLocale, I won't be able to easily determine if I should use another 
(possibly better) fallback.
  >  At the same time falling back to `QLocale::languageToString` is not 
necessarily in the interest of the user either. Who's to say the user will know 
what a language means in English.
  > 
  > So, I haven't give this a great deal of thought, but it seems that always 
returning QString(), if we cannot resolve a string internally, is possibly more 
flexible. Worst case the consumer has to do:
  > 
  >   str = KLanguageName::nameForCode("fr")
  >   if (str.isEmpty()) { str = QLocale("fr").nativeLanguageName() }
  > 
  > 
  > Which isn't that much code TBH.
  
  But you end up repeating that in lots of places (which we should there's lots 
of places that suffer from trying to guess a language name at this point, and 
all of them went the bad way one way or another). If you want to give some 
random potential user more flexibility i'm fine with that, add some flags, but 
i want the "give me the best you can do" possibility to still work. Maybe we 
should even never return an empty string and worst case scenario return code 
back.

REPOSITORY
  R265 KConfigWidgets

REVISION DETAIL
  https://phabricator.kde.org/D10446

To: aacid
Cc: kde-frameworks-devel, sitter, markg, apol, michaelh, ngraham, bruns

D10446: Add KLanguageName

[Harald Sitter]

sitter added a comment.


  Stacking the functions seems to work fine
  
QString KLanguageName::nameForCode(const QString )
{
const QStringList parts = QLocale().name().split(QChar('_'));
return nameForCodeInLocale(code, parts.at(0));
}
  
  I do have various refinements and fixes for the logic plus a unit test I can 
update the diff if you are ok with that.
  
  As for kcoreaddons, I don't think we could go there with kconfig could we? 
And I am not sure QSettings is up to the task?
  
  I also have some behavior concerns. The auto-fallback to QLocale is super 
handy, but isn't very flexible: As an application author I might have another 
way to map a language to a pretty string, if KLanguageName automatically falls 
back to QLocale, I won't be able to easily determine if I should use another 
(possibly better) fallback.
  At the same time falling back to `QLocale::languageToString` is not 
necessarily in the interest of the user either. Who's to say the user will know 
what a language means in English.
  
  So, I haven't give this a great deal of thought, but it seems that always 
returning QString(), if we cannot resolve a string internally, is possibly more 
flexible. Worst case the consumer has to do:
  
str = KLanguageName::nameForCode("fr")
if (str.isEmpty()) { str = QLocale("fr").nativeLanguageName() }
  
  Which isn't that much code TBH.

REPOSITORY
  R265 KConfigWidgets

REVISION DETAIL
  https://phabricator.kde.org/D10446

To: aacid
Cc: kde-frameworks-devel, sitter, markg, apol, michaelh, ngraham, bruns

D10446: Add KLanguageName

[Albert Astals Cid]

aacid added a comment.


  > @aacid what were the changes you had planned here?
  
  As Aleix mentioned the two methods can probably be made to call eachother, or 
maybe not, but needs to be investigated and an answer given to why not if not 
possible.

REPOSITORY
  R265 KConfigWidgets

REVISION DETAIL
  https://phabricator.kde.org/D10446

To: aacid
Cc: kde-frameworks-devel, sitter, markg, apol, michaelh, ngraham, bruns

D10446: Add KLanguageName

[Harald Sitter]

sitter added a comment.
Herald edited subscribers, added: kde-frameworks-devel; removed: Frameworks.


  @aacid what were the changes you had planned here?
  
  Does anyone else have thoughts on kcoreaddons vs. kconfigwidgets? I suppose 
we could move the class along with kf5_entry.desktop to kcoreaddons, since 
kconfigwidgets depends on kcoreaddons anyway it's a compatible change.

REPOSITORY
  R265 KConfigWidgets

REVISION DETAIL
  https://phabricator.kde.org/D10446

To: aacid
Cc: kde-frameworks-devel, sitter, markg, apol, michaelh, ngraham, bruns, 
#frameworks

D10446: Add KLanguageName

[Albert Astals Cid]

aacid planned changes to this revision.

REPOSITORY
  R265 KConfigWidgets

REVISION DETAIL
  https://phabricator.kde.org/D10446

To: aacid
Cc: markg, apol, #frameworks, michaelh

D10446: Add KLanguageName

[Albert Astals Cid]

aacid added a comment.


  In D10446#218954 , @markg wrote:
  
  > Isn't this better suited for KCoreAddons?
  
  
  The kf5_entry.desktop files are part of kconfigwidgets tarball, so that's why 
i put it here.

REPOSITORY
  R265 KConfigWidgets

REVISION DETAIL
  https://phabricator.kde.org/D10446

To: aacid
Cc: markg, apol, #frameworks, michaelh

D10446: Add KLanguageName

[Mark Gaiser]

markg added a comment.


  Isn't this better suited for KCoreAddons?
  
  On a related note, i did make this bug report for Qt: 
https://bugreports.qt.io/browse/QTBUG-64942 with regard to ISO 3166 country 
names. But language names also came up, see this 

 comment.
  
  I don't know of any progress there though.

REPOSITORY
  R265 KConfigWidgets

REVISION DETAIL
  https://phabricator.kde.org/D10446

To: aacid
Cc: markg, apol, #frameworks, michaelh

D10446: Add KLanguageName

[Aleix Pol Gonzalez]

apol added a comment.


  Makes sense to me anyway.
  
  Is there any other code that could use this API?

INLINE COMMENTS

> klanguagename.cpp:45
> +
> +return QString();
> +}

shouldn't this be equivalent to nameForCodeInLocale(code, QLocale().code())?

> klanguagename.cpp:65
> +entry.setLocale("en");
> +const QString englisName = group.readEntry("Name");
> +if (name != englisName) {

englishName

REPOSITORY
  R265 KConfigWidgets

REVISION DETAIL
  https://phabricator.kde.org/D10446

To: aacid
Cc: apol, #frameworks, michaelh

D10446: Add KLanguageName

[Albert Astals Cid]

aacid added a comment.


  ping?

REPOSITORY
  R265 KConfigWidgets

REVISION DETAIL
  https://phabricator.kde.org/D10446

To: aacid
Cc: #frameworks, michaelh

D10446: Add KLanguageName

[Albert Astals Cid]

aacid added a comment.


  With this i can finally stop using kdelibs4support in KTuberling

REPOSITORY
  R265 KConfigWidgets

REVISION DETAIL
  https://phabricator.kde.org/D10446

To: aacid
Cc: #frameworks, michaelh

D10446: Add KLanguageName

[Albert Astals Cid]

aacid created this revision.
Restricted Application added a project: Frameworks.
Restricted Application added a subscriber: Frameworks.
aacid requested review of this revision.

REVISION SUMMARY
  KLanguageName is a helper namespace that returns the name of a given language 
code.

REPOSITORY
  R265 KConfigWidgets

BRANCH
  master

REVISION DETAIL
  https://phabricator.kde.org/D10446

AFFECTED FILES
  src/CMakeLists.txt
  src/klanguagename.cpp
  src/klanguagename.h

To: aacid
Cc: #frameworks, michaelh