On March 2, 2015, 5:21 a.m., Jerome Leclanche wrote: > > Should we be using ::tr here instead of not translating at all? > > Jerome Leclanche wrote: > Consensus on IRC six days ago was that dropping translation altogether > was fine. > I can add some ::tr but it's arguable whether some of those values should > have been translated in the first place (eg. author names) > > Martin Gräßlin wrote: > I think ::tr would be better to keep the functionality and support for > the case that it shows up in UI again. (offtopic: there was a reason why > names should be translated, though I don't remember it.) > > Luigi Toscano wrote: > For example, names can be translitterated, or have inflections. > > For the future, please also ask i18n and don't just kill translations.
I think that adding the translations with argument "support for the case that it shows up in UI again." is not a good one - this creates more work for everyone (Jerome, i18n teams etc) with 0 outcome as the translations are nowhere to be seen (it's a daemon). I think that it should be added rather when the need arises, if ever... *shrug* - Martin ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/122680/#review76855 ----------------------------------------------------------- On March 2, 2015, 10 a.m., Jerome Leclanche wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > https://git.reviewboard.kde.org/r/122680/ > ----------------------------------------------------------- > > (Updated March 2, 2015, 10 a.m.) > > > Review request for KDE Frameworks, Localization and Translation (l10n), > Martin Gräßlin, and Martin Klapetek. > > > Repository: kglobalaccel > > > Description > ------- > > Remove the runtime's KAboutData > > The about data was unexposed, but created a dependency on KCoreAddons (for > KAboutData) and in turn on KI18n for the translations of the aboutData. > > This removes both dependencies as well as the string extraction scripts. > > -- > > Author notes: This is a RFC. We don't use kglobalaccel in LXQt but we would > like to, however it currently has too many dependencies. See > https://github.com/lxde/lxqt/issues/507 for related discussion. > I'm unsure myself if the about data is actually exposed somewhere I completely > missed, but it doesn't look that way. > > > Diffs > ----- > > CMakeLists.txt 68ad795 > src/runtime/CMakeLists.txt e639fa5 > src/runtime/globalshortcutsregistry.cpp 3e4d720 > src/runtime/kglobalacceld.cpp 4e7cb9d > src/runtime/main.cpp fdf4d62 > > Diff: https://git.reviewboard.kde.org/r/122680/diff/ > > > Testing > ------- > > Compiles and runs. No further testing done. > > > Thanks, > > Jerome Leclanche > >
_______________________________________________ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel