Moving Smb4K to extragear/network
Hello, a few weeks passed since Smb4K was uploaded to kdereview. Thank you very much for the suggestions to improve the software and for your help. Since all issues have been fixed that emerged during this period, I would like to move Smb4K to extragear/network. If there are no objections, I plan to file a sysadmin bug around next weekend. Best regards Alexander
Re: Review Request 115964: Oxygen: avoid calls to reparseConfiguration() on startup.
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/115964/#review50797 --- Right now, I'm not able to compile, due to: home/hpereira/kf5/src/kde-workspace/kstyles/oxygen/oxygenstyle.cpp: In constructor ‘Oxygen::Style::Style()’: /home/hpereira/kf5/src/kde-workspace/kstyles/oxygen/oxygenstyle.cpp:193:60: error: ‘class Oxygen::StyleConfigData’ has no member named ‘sharedConfig’ _helper( new StyleHelper( StyleConfigData::self()-sharedConfig() ) ), Does this review depend on some pending changes in kconfig ? - Hugo Pereira Da Costa On Feb. 23, 2014, 12:08 p.m., David Faure wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/115964/ --- (Updated Feb. 23, 2014, 12:08 p.m.) Review request for kde-workspace and Hugo Pereira Da Costa. Repository: kde-workspace Description --- Oxygen: avoid calls to reparseConfiguration() on startup. strace -e open kate | grep -v NOENT | grep oxygenrc | wc -l went from 8 to 4 (and when looking for kdeglobals, from 13 to 11) There's still a lot of work to be done in that area... (within KConfigSkeleton, and probably kdeplatformtheme) Diffs - kstyles/oxygen/oxygenshadowhelper.h 066edd3292f390401691a9d6e5182e9dc6d24133 kstyles/oxygen/oxygenshadowhelper.cpp b3f3d0c876067292a72647e9fcda07cbbf4ba4b0 kstyles/oxygen/oxygenstyle.h 35323b4578eb9aa0d1efcc5901bab80fadea64f3 kstyles/oxygen/oxygenstyle.cpp f6ff24ad515003ad031c80665935e6d113b5a1e5 kstyles/oxygen/oxygenstylehelper.h 57b86c7ed540364040e87a8464299db17c460647 kstyles/oxygen/oxygenstylehelper.cpp f2af4172c5beb8b8c3bb0d75b5eb351dc710289e kwin/clients/oxygen/demo/oxygenshadowdemodialog.cpp 9e1481cab4cca2961b48c791e72d925ae4a83d05 kwin/clients/oxygen/oxygendecohelper.h 4c9a44ab54edec7bdc428f33e580efc60efdf235 kwin/clients/oxygen/oxygendecohelper.cpp e6bbcbf9df7eee3188c84cd74f0e32b7cfd162d3 kwin/clients/oxygen/oxygenfactory.h 9ed90ec1567ed537a3524b2d4a507a3471341a64 kwin/clients/oxygen/oxygenfactory.cpp 6d5b08b9160a7794f668feb2914450b602360ce6 libs/oxygen/oxygenhelper.h ee381a74320da172e834550f61ef214377870bfc libs/oxygen/oxygenhelper.cpp cd6562b411fdb1bce6d0c740a4b38dae33218324 Diff: https://git.reviewboard.kde.org/r/115964/diff/ Testing --- Thanks, David Faure
Re: Review Request 115964: Oxygen: avoid calls to reparseConfiguration() on startup.
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/115964/ --- (Updated Feb. 25, 2014, 12:02 p.m.) Review request for kde-workspace and Hugo Pereira Da Costa. Changes --- add dep Repository: kde-workspace Description --- Oxygen: avoid calls to reparseConfiguration() on startup. strace -e open kate | grep -v NOENT | grep oxygenrc | wc -l went from 8 to 4 (and when looking for kdeglobals, from 13 to 11) There's still a lot of work to be done in that area... (within KConfigSkeleton, and probably kdeplatformtheme) Diffs - kstyles/oxygen/oxygenshadowhelper.h 066edd3292f390401691a9d6e5182e9dc6d24133 kstyles/oxygen/oxygenshadowhelper.cpp b3f3d0c876067292a72647e9fcda07cbbf4ba4b0 kstyles/oxygen/oxygenstyle.h 35323b4578eb9aa0d1efcc5901bab80fadea64f3 kstyles/oxygen/oxygenstyle.cpp f6ff24ad515003ad031c80665935e6d113b5a1e5 kstyles/oxygen/oxygenstylehelper.h 57b86c7ed540364040e87a8464299db17c460647 kstyles/oxygen/oxygenstylehelper.cpp f2af4172c5beb8b8c3bb0d75b5eb351dc710289e kwin/clients/oxygen/demo/oxygenshadowdemodialog.cpp 9e1481cab4cca2961b48c791e72d925ae4a83d05 kwin/clients/oxygen/oxygendecohelper.h 4c9a44ab54edec7bdc428f33e580efc60efdf235 kwin/clients/oxygen/oxygendecohelper.cpp e6bbcbf9df7eee3188c84cd74f0e32b7cfd162d3 kwin/clients/oxygen/oxygenfactory.h 9ed90ec1567ed537a3524b2d4a507a3471341a64 kwin/clients/oxygen/oxygenfactory.cpp 6d5b08b9160a7794f668feb2914450b602360ce6 libs/oxygen/oxygenhelper.h ee381a74320da172e834550f61ef214377870bfc libs/oxygen/oxygenhelper.cpp cd6562b411fdb1bce6d0c740a4b38dae33218324 Diff: https://git.reviewboard.kde.org/r/115964/diff/ Testing --- Thanks, David Faure
Re: Review Request 115964: Oxygen: avoid calls to reparseConfiguration() on startup.
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/115964/#review50816 --- Ship it! code is good and works well. Thanks ! - Hugo Pereira Da Costa On Feb. 25, 2014, 12:02 p.m., David Faure wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/115964/ --- (Updated Feb. 25, 2014, 12:02 p.m.) Review request for kde-workspace and Hugo Pereira Da Costa. Repository: kde-workspace Description --- Oxygen: avoid calls to reparseConfiguration() on startup. strace -e open kate | grep -v NOENT | grep oxygenrc | wc -l went from 8 to 4 (and when looking for kdeglobals, from 13 to 11) There's still a lot of work to be done in that area... (within KConfigSkeleton, and probably kdeplatformtheme) Diffs - kstyles/oxygen/oxygenshadowhelper.h 066edd3292f390401691a9d6e5182e9dc6d24133 kstyles/oxygen/oxygenshadowhelper.cpp b3f3d0c876067292a72647e9fcda07cbbf4ba4b0 kstyles/oxygen/oxygenstyle.h 35323b4578eb9aa0d1efcc5901bab80fadea64f3 kstyles/oxygen/oxygenstyle.cpp f6ff24ad515003ad031c80665935e6d113b5a1e5 kstyles/oxygen/oxygenstylehelper.h 57b86c7ed540364040e87a8464299db17c460647 kstyles/oxygen/oxygenstylehelper.cpp f2af4172c5beb8b8c3bb0d75b5eb351dc710289e kwin/clients/oxygen/demo/oxygenshadowdemodialog.cpp 9e1481cab4cca2961b48c791e72d925ae4a83d05 kwin/clients/oxygen/oxygendecohelper.h 4c9a44ab54edec7bdc428f33e580efc60efdf235 kwin/clients/oxygen/oxygendecohelper.cpp e6bbcbf9df7eee3188c84cd74f0e32b7cfd162d3 kwin/clients/oxygen/oxygenfactory.h 9ed90ec1567ed537a3524b2d4a507a3471341a64 kwin/clients/oxygen/oxygenfactory.cpp 6d5b08b9160a7794f668feb2914450b602360ce6 libs/oxygen/oxygenhelper.h ee381a74320da172e834550f61ef214377870bfc libs/oxygen/oxygenhelper.cpp cd6562b411fdb1bce6d0c740a4b38dae33218324 Diff: https://git.reviewboard.kde.org/r/115964/diff/ Testing --- Thanks, David Faure
Re: Lokalization for KDE AppStream AppData files
Hi again! I talked to some people, and it looks like merging the translation back into one file using existing tools is not possible. So it would be hacking a custom solution or not merge everything into one file. I don't want to write additional code if doesn't have a strong advantage. So, I would like to ask if my previous suggestion, projects create an .appdata.xml.in file and the l10n-script commits localization back as .appdata.xml into the same directory, would be an acceptable solution. I don't see disadvantages of this. Some XML-localization code exists, but that is Docbook-specific and can't easily be reused for that kind of translation (as far as I can see, it also requires l10n data to be present before the localized XML can be built) Cheers, Matthias
Re: Lokalization for KDE AppStream AppData files
Notice that I don't care much about i18n at all (so i don't intend nor could argue), just curious: On Dienstag, 25. Februar 2014 15:13:07 CEST, Matthias Klumpp wrote: Hi again! I talked to some people, and it looks like merging the translation back into one file using existing tools is not possible. From what i understood the issue is that intltool needs a _prefixed tag to separate translatable from untranslatable elements. Would not p lang=x (assuming x to be some invalid lang ID - i do not care about i18n...) be sufficient in that regard? Is intltool really incapable of selecting a specialized lang as translation source? Cheers, Thomas
KF5 Update Meeting Minutes 2014-w9
Hello everyone, This is the minutes of the Week 9 KF5 meeting. As usual it has been held on #kde-devel at 4pm Paris time. Were present: alexmerry, dfaure, krake, mgraesslin, teo, tosky and myself. Announcement: * Alpha 2 will be prepared on saturday; * Please push toward completion of the still in progress tasks, we're drifting away putting the release at risk: http://community.kde.org/Frameworks/Epics/KF5.0_Release_Preparation ; * For instance, the merge of the kdnssd repos is still not done, while it's a large change we'd want in alpha 2! * alexmerry is putting e-c-m in shape for release; * there's more to do but he wouldn't feel bad releasing 1.0 as is; * he'd like more comments on http://mail.kde.org/pipermail/kde-frameworks-devel/2014-February/011667.html ; * he's also fixed a history screw up in kdoctools last chance to complain: http://lists.kde.org/?l=kde-frameworks-develm=139325409324248w=3 ; * dfaure posted review requests for KConfig waiting for its maintainer to react (added in CC); * krake ported ki18n to qtscript which makes it tier 1 (and kunitconversion tier2, etc.); * mgraesslin worked a bit on e-c-m; * he created FindEGL and FindWayland modules; * he also improved FindXCB thanks to alexmerry new documentation; * teo is still working on kwallet compatibility in ksecretservices; * he noted that kwallet.cpp is a huge mess of ifdefs with partial ksecrets support; * tosky is waiting feedback on http://lists.kde.org/?l=kde-frameworks-develm=139308438015018w=3 ; * ervin helped with reviews, reviewed everything from last week; * he also worried about the lack of progress on the release prep epic, which led to discussions with dfaure and alexmerry to drop some of the tasks; If you got questions, feel free to ask. Regards. -- Kévin Ottens, http://ervin.ipsquad.net KDAB - proud supporter of KDE, http://www.kdab.com signature.asc Description: This is a digitally signed message part.
Review Request 116048: Remove Content-Type header when redirecting to GET
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/116048/ --- Review request for kdelibs and Dawit Alemayehu. Repository: kdelibs Description --- This fix is for stable branch KDE/4.12 and it's needed because of latest changes in redirection code handling. Noticed while reviewing https://git.reviewboard.kde.org/r/116017/ (Dawit, you may want to rebase it if this goes in). Diffs - kio/kio/job.cpp 9cf2b57 Diff: https://git.reviewboard.kde.org/r/116048/diff/ Testing --- various Thanks, Andrea Iacovitti
Re: Lokalization for KDE AppStream AppData files
2014-02-25 16:15 GMT+01:00 Thomas Lübking thomas.luebk...@gmail.com: Notice that I don't care much about i18n at all (so i don't intend nor could argue), just curious: On Dienstag, 25. Februar 2014 15:13:07 CEST, Matthias Klumpp wrote: Hi again! I talked to some people, and it looks like merging the translation back into one file using existing tools is not possible. From what i understood the issue is that intltool needs a _prefixed tag to separate translatable from untranslatable elements. Yes Would not p lang=x (assuming x to be some invalid lang ID - i do not care about i18n...) be sufficient in that regard? Is intltool really incapable of selecting a specialized lang as translation source? Well, it's not how that XML stuff is translated... Also, we need a translation template/fallback-tag for each localized tag, so it is absolutely a sane thing to do. There also is itstool, which resceives a definition of translatable elements in order to translate XML, which is pretty neat. However, it expects an untranslated XML-file as input and returns the tramslated version. If you give it a translated file, it duplicates tags there (which is even documented), and there seems to be no option to turn it off. All people I asked either asked why I couldn't simply store the template somewhere or why I would want to translate a translated file ;-) So, it appears there is no standard way to handle this case, and I see no disadvantage in having Scripty commit a trsnalted file as separate file. It's a bit... magic and people should be aware of that when they add AppData, but apart from that I don't see disadvantages. If someone writes an XML translator which does whatever needed to translate translated files, I'd be happy with that as well, but I think doing that would be a waste of time. Cheers, Matthias -- Debian Developer | Freedesktop-Developer I welcome VSRE emails. See http://vsre.info/
Re: Lokalization for KDE AppStream AppData files
On Tuesday, 2014-02-25, 18:45:52, Matthias Klumpp wrote: 2014-02-25 16:15 GMT+01:00 Thomas Lübking thomas.luebk...@gmail.com: Notice that I don't care much about i18n at all (so i don't intend nor could argue), just curious: On Dienstag, 25. Februar 2014 15:13:07 CEST, Matthias Klumpp wrote: Hi again! I talked to some people, and it looks like merging the translation back into one file using existing tools is not possible. From what i understood the issue is that intltool needs a _prefixed tag to separate translatable from untranslatable elements. Yes Would not p lang=x (assuming x to be some invalid lang ID - i do not care about i18n...) be sufficient in that regard? Is intltool really incapable of selecting a specialized lang as translation source? Well, it's not how that XML stuff is translated... Also, we need a translation template/fallback-tag for each localized tag, so it is absolutely a sane thing to do. There also is itstool, which resceives a definition of translatable elements in order to translate XML, which is pretty neat. So itstool at least allows the template file to be a valid file? Cheers, Kevin -- Kevin Krammer, KDE developer, xdg-utils developer KDE user support, developer mentoring signature.asc Description: This is a digitally signed message part.
Re: Lokalization for KDE AppStream AppData files
2014-02-25 18:56 GMT+01:00 Kevin Krammer kram...@kde.org: On Tuesday, 2014-02-25, 18:45:52, Matthias Klumpp wrote: 2014-02-25 16:15 GMT+01:00 Thomas Lübking thomas.luebk...@gmail.com: Notice that I don't care much about i18n at all (so i don't intend nor could argue), just curious: On Dienstag, 25. Februar 2014 15:13:07 CEST, Matthias Klumpp wrote: Hi again! I talked to some people, and it looks like merging the translation back into one file using existing tools is not possible. From what i understood the issue is that intltool needs a _prefixed tag to separate translatable from untranslatable elements. Yes Would not p lang=x (assuming x to be some invalid lang ID - i do not care about i18n...) be sufficient in that regard? Is intltool really incapable of selecting a specialized lang as translation source? Well, it's not how that XML stuff is translated... Also, we need a translation template/fallback-tag for each localized tag, so it is absolutely a sane thing to do. There also is itstool, which resceives a definition of translatable elements in order to translate XML, which is pretty neat. So itstool at least allows the template file to be a valid file? Yes, it will be just like a not-localized AppData file :-) -- Debian Developer | Freedesktop-Developer I welcome VSRE emails. See http://vsre.info/
Re: Lokalization for KDE AppStream AppData files
On Tuesday, 2014-02-25, 20:16:57, Albert Astals Cid wrote: El Dimarts, 25 de febrer de 2014, a les 15:13:07, Matthias Klumpp va escriure: Hi again! I talked to some people, and it looks like merging the translation back into one file using existing tools is not possible. So it would be hacking a custom solution or not merge everything into one file. I don't want to write additional code if doesn't have a strong advantage. So, I would like to ask if my previous suggestion, projects create an .appdata.xml.in file and the l10n-script commits localization back as .appdata.xml into the same directory, would be an acceptable solution. And then people will go and edit the english version in .appdata.xml and the translations will get out of sync. script/theothertool could probably add an XML comment, something like this is a generate file, do not edit, edit source file xyz instead. Cheers, Kevin -- Kevin Krammer, KDE developer, xdg-utils developer KDE user support, developer mentoring signature.asc Description: This is a digitally signed message part.
Re: Lokalization for KDE AppStream AppData files
El Dimarts, 25 de febrer de 2014, a les 20:24:12, Kevin Krammer va escriure: On Tuesday, 2014-02-25, 20:16:57, Albert Astals Cid wrote: El Dimarts, 25 de febrer de 2014, a les 15:13:07, Matthias Klumpp va escriure: Hi again! I talked to some people, and it looks like merging the translation back into one file using existing tools is not possible. So it would be hacking a custom solution or not merge everything into one file. I don't want to write additional code if doesn't have a strong advantage. So, I would like to ask if my previous suggestion, projects create an .appdata.xml.in file and the l10n-script commits localization back as .appdata.xml into the same directory, would be an acceptable solution. And then people will go and edit the english version in .appdata.xml and the translations will get out of sync. script/theothertool could probably add an XML comment, something like this is a generate file, do not edit, edit source file xyz instead. It could, as well as it could work on a single file, but does it do that? Cheers, Albert Cheers, Kevin
Re: Lokalization for KDE AppStream AppData files
2014-02-25 20:38 GMT+01:00 Kevin Krammer kram...@kde.org: On Tuesday, 2014-02-25, 20:32:49, Albert Astals Cid wrote: El Dimarts, 25 de febrer de 2014, a les 20:24:12, Kevin Krammer va escriure: On Tuesday, 2014-02-25, 20:16:57, Albert Astals Cid wrote: El Dimarts, 25 de febrer de 2014, a les 15:13:07, Matthias Klumpp va escriure: Hi again! I talked to some people, and it looks like merging the translation back into one file using existing tools is not possible. So it would be hacking a custom solution or not merge everything into one file. I don't want to write additional code if doesn't have a strong advantage. So, I would like to ask if my previous suggestion, projects create an .appdata.xml.in file and the l10n-script commits localization back as .appdata.xml into the same directory, would be an acceptable solution. And then people will go and edit the english version in .appdata.xml and the translations will get out of sync. script/theothertool could probably add an XML comment, something like this is a generate file, do not edit, edit source file xyz instead. It could, as well as it could work on a single file, but does it do that? No idea, but prepending a comment sounds easy compared to the other thing :) And the workflow of both intltool and itstool suggest that they always consider their output to be fully generated and not editable so they should really have the option of writing such a warning. Just like UIC does or MOC. Only developers should have to edit that file - translators will translate the po file which is used by itstool/intltool to translate the XML. And I consider developers to be smart enough to edit the source-file and not the generated one (print a warning somewhere might be a good idea anyway...) Itstool has a nice summary of the workflow described here: http://itstool.org/documentation/basic-usage/ -- Debian Developer | Freedesktop-Developer I welcome VSRE emails. See http://vsre.info/
Re: Lokalization for KDE AppStream AppData files
On Tuesday, 2014-02-25, 21:15:36, Matthias Klumpp wrote: 2014-02-25 20:38 GMT+01:00 Kevin Krammer kram...@kde.org: And the workflow of both intltool and itstool suggest that they always consider their output to be fully generated and not editable so they should really have the option of writing such a warning. Just like UIC does or MOC. Only developers should have to edit that file - translators will translate the po file which is used by itstool/intltool to translate the XML. Well, my understanding was that nobody will edit that file. Developers would edit the template, translators would edit po files and the tool generates the appdata file, no? And I consider developers to be smart enough to edit the source-file and not the generated one (print a warning somewhere might be a good idea anyway...) It is always good to have an additional hint. Usually tools that generate output that is overwritten everytime the tool runs generate such a warning header. I had kind of assumed that intltool and itstool would do the same since their output is, as far as my unterstanding was, not meant to be edited. Itstool has a nice summary of the workflow described here: http://itstool.org/documentation/basic-usage/ It seems to recommend the generated file approach: When using join mode, it’s common to maintain a monolingual version of the file along with translations in PO files, and to build the multilingual file that gets shipped. Couldn't hurt for it to have an option to generate a warning into as well. A lot of tools that produce such overwrite content do. Anyway, prepending a comment could even be done by script that runs the tool I guess. Cheers, Kevin -- Kevin Krammer, KDE developer, xdg-utils developer KDE user support, developer mentoring signature.asc Description: This is a digitally signed message part.
Re: Lokalization for KDE AppStream AppData files
On Tuesday, 2014-02-25, 21:36:27, Albert Astals Cid wrote: El Dimarts, 25 de febrer de 2014, a les 21:15:36, Matthias Klumpp va escriure: 2014-02-25 20:38 GMT+01:00 Kevin Krammer kram...@kde.org: And the workflow of both intltool and itstool suggest that they always consider their output to be fully generated and not editable so they should really have the option of writing such a warning. Just like UIC does or MOC. Only developers should have to edit that file - translators will translate the po file which is used by itstool/intltool to translate the XML. And I consider developers to be smart enough to edit the source-file and not the generated one (print a warning somewhere might be a good idea anyway...) You're overestimating people. Itstool has a nice summary of the workflow described here: http://itstool.org/documentation/basic-usage/ I don't care about that, we have a workflow, if your tool doesn't support our worflow, your tool is wrong. It seems the tools available from other communities with similar needs do not match our needs closely enough. We'll probably have to create a tool that fits our needs then. Cheers, Kevin -- Kevin Krammer, KDE developer, xdg-utils developer KDE user support, developer mentoring signature.asc Description: This is a digitally signed message part.
Re: Lokalization for KDE AppStream AppData files
2014-02-25 21:51 GMT+01:00 Kevin Krammer kram...@kde.org: On Tuesday, 2014-02-25, 21:36:27, Albert Astals Cid wrote: El Dimarts, 25 de febrer de 2014, a les 21:15:36, Matthias Klumpp va escriure: 2014-02-25 20:38 GMT+01:00 Kevin Krammer kram...@kde.org: And the workflow of both intltool and itstool suggest that they always consider their output to be fully generated and not editable so they should really have the option of writing such a warning. Just like UIC does or MOC. Only developers should have to edit that file - translators will translate the po file which is used by itstool/intltool to translate the XML. And I consider developers to be smart enough to edit the source-file and not the generated one (print a warning somewhere might be a good idea anyway...) You're overestimating people. Itstool has a nice summary of the workflow described here: http://itstool.org/documentation/basic-usage/ I don't care about that, we have a workflow, if your tool doesn't support our worflow, your tool is wrong. If that is your final statement, I will write the AppData recommendation without any translation support for KDE. There is no tool available which does what you want, and I can't take the task to write one (I also consider it useless, but that's unrelated). Having untranslated AppData is better than no AppData. It seems the tools available from other communities with similar needs do not match our needs closely enough. We'll probably have to create a tool that fits our needs then. That would work, ov course :-) Cheers, Matthias -- Debian Developer | Freedesktop-Developer I welcome VSRE emails. See http://vsre.info/
Re: Lokalization for KDE AppStream AppData files
2014-02-25 21:49 GMT+01:00 Kevin Krammer kram...@kde.org: On Tuesday, 2014-02-25, 21:15:36, Matthias Klumpp wrote: 2014-02-25 20:38 GMT+01:00 Kevin Krammer kram...@kde.org: And the workflow of both intltool and itstool suggest that they always consider their output to be fully generated and not editable so they should really have the option of writing such a warning. Just like UIC does or MOC. Only developers should have to edit that file - translators will translate the po file which is used by itstool/intltool to translate the XML. Well, my understanding was that nobody will edit that file. Developers would edit the template, translators would edit po files and the tool generates the appdata file, no? Yes, that is the workflow. The generated file would just be committed to the Git repo. And I consider developers to be smart enough to edit the source-file and not the generated one (print a warning somewhere might be a good idea anyway...) It is always good to have an additional hint. Usually tools that generate output that is overwritten everytime the tool runs generate such a warning header. I had kind of assumed that intltool and itstool would do the same since their output is, as far as my unterstanding was, not meant to be edited. Itstool has a nice summary of the workflow described here: http://itstool.org/documentation/basic-usage/ It seems to recommend the generated file approach: When using join mode, it’s common to maintain a monolingual version of the file along with translations in PO files, and to build the multilingual file that gets shipped. Jup - I haven't found someone yet who has translation merged in the XML (and I searched for that, so we could use whatever they would use, but nobody does it, apparently). Couldn't hurt for it to have an option to generate a warning into as well. A lot of tools that produce such overwrite content do. That would be trivial - if the tool doesn't support it, we could postprocess the generated file and add it. Anyway, prepending a comment could even be done by script that runs the tool I guess. :-) Cheers, Matthias -- Debian Developer | Freedesktop-Developer I welcome VSRE emails. See http://vsre.info/
Re: Lokalization for KDE AppStream AppData files
On Dienstag, 25. Februar 2014 22:22:36 CEST, Matthias Klumpp wrote: 2014-02-25 21:51 GMT+01:00 Kevin Krammer kram...@kde.org: On Tuesday, 2014-02-25, 21:36:27, Albert Astals Cid wrote: ... If that is your final statement, I will write the AppData recommendation without any translation support for KDE. There is no tool available which does what you want, and I can't take the task to write one (I also consider it useless, but that's unrelated). Recap: the desired action is to have file.xml - p lang=xfoo bar/p and turn that into file.xml - p lang=xfoo bar/p p lang=enfoo bar/p p lang=deföö bär/p p lang=frle fó et la bàr/p p lang=esel fobarro/p intltool/itstool /can/ select p lang=xfoo bar/p as translation source, correct? It creates a .po file for the translators and can write back an xml file (from the .po), but only /extend/ p lang=xfoo bar/p, not merge with existing translations - correct? So the outstanding task would be to kick all pre-translated p lang=!x elements before running the pass which writes the translated xml file? That frankly sounds like an xmlstarlet one-liner... is that the problem? Cheers, Thomas PS: Having untranslated AppData is better than no AppData. *LOL* - i'll bring that argument next time i want to introduce a visual string in a minor release ... :-P
Re: Lokalization for KDE AppStream AppData files
2014-02-25 22:57 GMT+01:00 Thomas Lübking thomas.luebk...@gmail.com: On Dienstag, 25. Februar 2014 22:22:36 CEST, Matthias Klumpp wrote: 2014-02-25 21:51 GMT+01:00 Kevin Krammer kram...@kde.org: On Tuesday, 2014-02-25, 21:36:27, Albert Astals Cid wrote: ... If that is your final statement, I will write the AppData recommendation without any translation support for KDE. There is no tool available which does what you want, and I can't take the task to write one (I also consider it useless, but that's unrelated). Recap: the desired action is to have file.xml - p lang=xfoo bar/p and turn that into file.xml - p lang=xfoo bar/p p lang=enfoo bar/p p lang=deföö bär/p p lang=frle fó et la bàr/p p lang=esel fobarro/p No, it takes pfoo bar/p and turns that into pfoo bar/p p lang=enfoo bar/p p lang=deföö bär/p p lang=frle fó et la bàr/p p lang=esel fobarro/p intltool/itstool /can/ select p lang=xfoo bar/p as translation source, correct? The only use p or, in intltool's case every tag prefixed with an underscore, like _p. It creates a .po file for the translators and can write back an xml file (from the .po), but only /extend/ p lang=xfoo bar/p, not merge with existing translations - correct? If you thow in a translated file, they will duplicate the translated tag, right. So the outstanding task would be to kick all pre-translated p lang=!x elements before running the pass which writes the translated xml file? Yes, that would basically recreate the original input file :-) That frankly sounds like an xmlstarlet one-liner... is that the problem? How would that look like? That would be really cool :-) (I never worked with xmlstarlet) Having untranslated AppData is better than no AppData. *LOL* - i'll bring that argument next time i want to introduce a visual string in a minor release ... :-P Given that Fedora wants to kick out all apps without AppData from their software center, that might be a relevant issue ;-) Cheers, Matthias -- Debian Developer | Freedesktop-Developer I welcome VSRE emails. See http://vsre.info/
Re: Lokalization for KDE AppStream AppData files
On Dienstag, 25. Februar 2014 23:20:18 CEST, Matthias Klumpp wrote: No, it takes pfoo bar/p and turns that into pfoo bar/p p lang=enfoo bar/p p lang=deföö bär/p p lang=frle fó et la bàr/p p lang=esel fobarro/p I thought, plain p would *not* to be translated? However, same procedure. That frankly sounds like an xmlstarlet one-liner... is that the problem? How would that look like? That would be really cool :-) (I never worked with xmlstarlet) $ xml ed -d //*/p[@lang!='x'] /path/to/appdata.xml resp. (matches all elements, not just p) $ xml ed -d //*[@lang!='x'] /path/to/appdata.xml This will delete all (p) elements that have a lang attribute which is not x $ xml ed -d //*[@lang] /path/to/appdata.xml deletes all elements with a lang attribute You can also select subpaths (//* globs) $ xml ed -d //*/div[@align!='center']/*[@lang] /path/to/appdata.xml -- OT Given that Fedora wants to kick out all apps without AppData from their software center You mean I should simply stress my point with a gun? Seriously, i'd just ignore such attempts to threaten by we will ship a crippled package manager that does not show your software. It's not a very scary threat (they'll probably get bug reports), inacceptable style and certainly no base to start any discussion. Cheers, Thomas
Re: Lokalization for KDE AppStream AppData files
2014-02-25 23:41 GMT+01:00 Thomas Lübking thomas.luebk...@gmail.com: On Dienstag, 25. Februar 2014 23:20:18 CEST, Matthias Klumpp wrote: No, it takes pfoo bar/p and turns that into pfoo bar/p p lang=enfoo bar/p p lang=deföö bär/p p lang=frle fó et la bàr/p p lang=esel fobarro/p I thought, plain p would *not* to be translated? However, same procedure. They won't be translated, but will still be in the resulting XML file. [...] You can also select subpaths (//* globs) $ xml ed -d //*/div[@align!='center']/*[@lang] /path/to/appdata.xml This looks good! Let's see if I can come up with something useful... (Scripty is a bit confusing, still) -- OT Given that Fedora wants to kick out all apps without AppData from their software center You mean I should simply stress my point with a gun? Seriously, i'd just ignore such attempts to threaten by we will ship a crippled package manager that does not show your software. It's not a very scary threat (they'll probably get bug reports), inacceptable style and certainly no base to start any discussion. Well, it's not a threat. I am no Fedora guy and don't care at all about what they show or not show in their software centers. But it's a point to be aware of, and even untranslated metadata is already helpful to display applications in any software center. -- Debian Developer | Freedesktop-Developer I welcome VSRE emails. See http://vsre.info/
Re: Lokalization for KDE AppStream AppData files
On Dienstag, 25. Februar 2014 23:45:59 CEST, Matthias Klumpp wrote: Well, it's not a threat. That's my point ;-) I am no Fedora guy I didn't mean to imply that or that you were trying to threat anyone - just that If you don't do this, i'll get myself bugreports is certainly nothing that would cause me to act at all, let alone acting hasty. Cheers, Thomas
Re: Lokalization for KDE AppStream AppData files
On Tuesday, 2014-02-25, 23:20:18, Matthias Klumpp wrote: 2014-02-25 22:57 GMT+01:00 Thomas Lübking thomas.luebk...@gmail.com: Recap: the desired action is to have file.xml - p lang=xfoo bar/p and turn that into file.xml - p lang=xfoo bar/p p lang=enfoo bar/p p lang=deföö bär/p p lang=frle fó et la bàr/p p lang=esel fobarro/p No, it takes pfoo bar/p and turns that into pfoo bar/p p lang=enfoo bar/p p lang=deföö bär/p p lang=frle fó et la bàr/p p lang=esel fobarro/p That looks fine. Basically like for .desktop files, which also adds the translated entries after the source entry. Given that Fedora wants to kick out all apps without AppData from their software center, that might be a relevant issue ;-) My understanding was that this only impacts the GNOME software thingy. It is not a general rule all package manager frontends on Fedora have to follow. But I could have misunderstood something. Cheers, Kevin -- Kevin Krammer, KDE developer, xdg-utils developer KDE user support, developer mentoring signature.asc Description: This is a digitally signed message part.
Re: Lokalization for KDE AppStream AppData files
2014-02-26 0:14 GMT+01:00 Kevin Krammer kram...@kde.org: On Tuesday, 2014-02-25, 23:20:18, Matthias Klumpp wrote: 2014-02-25 22:57 GMT+01:00 Thomas Lübking thomas.luebk...@gmail.com: Recap: the desired action is to have file.xml - p lang=xfoo bar/p and turn that into file.xml - p lang=xfoo bar/p p lang=enfoo bar/p p lang=deföö bär/p p lang=frle fó et la bàr/p p lang=esel fobarro/p No, it takes pfoo bar/p and turns that into pfoo bar/p p lang=enfoo bar/p p lang=deföö bär/p p lang=frle fó et la bàr/p p lang=esel fobarro/p That looks fine. Basically like for .desktop files, which also adds the translated entries after the source entry. Given that Fedora wants to kick out all apps without AppData from their software center, that might be a relevant issue ;-) My understanding was that this only impacts the GNOME software thingy. It is not a general rule all package manager frontends on Fedora have to follow. But I could have misunderstood something. This affects the AppStream data they are generating - if they don't ship that data, all AppStream-based software centers are affected - the SC application itself doesn't know at all where the data comes from (and that's a good thing!). However, the official recommendation is to include everything which has a .desktop-file and/or AppData file. -- Debian Developer | Freedesktop-Developer I welcome VSRE emails. See http://vsre.info/
Re: Moving Baloo forward
On Tuesday 21. January 2014 16.04.51 Vishesh Handa wrote: Well, anything is possible. Someone would just need to implement it. We had wanted to do something similar during the Nepomuk days as well, but it didn't quite materialize. Point me to roughly where in the stack to implement it, and I'll look into implement support for multimedia files. :-) -- Martin Sandsmark
Re: Moving Baloo forward
On Tuesday 21. January 2014 14.54.39 Thomas Lübking wrote: I *do* consider xattr the BY FAR more sane approach to the problem, but currently do frankly not see this on end user desktops :-( Luckily, we develop end-user desktops and the people who develop the other parts of this system are normal human beings that we can talk to. I'd suggest using xattrs, and get distro people to start enabling it by default. Other things to do would be to gray out the metadata editing stuff when viewing files on a filesystem without xattrs, with a short explanation, and get kio to warn you when you try to copy files with xattrs to a filesystem that doesn't support xattrs. -- Martin Sandsmark
Re: Review Request 116048: Remove Content-Type header when redirecting to GET
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/116048/#review50896 --- Ship it! Ship It! - Dawit Alemayehu On Feb. 25, 2014, 4:21 p.m., Andrea Iacovitti wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/116048/ --- (Updated Feb. 25, 2014, 4:21 p.m.) Review request for kdelibs and Dawit Alemayehu. Repository: kdelibs Description --- This fix is for stable branch KDE/4.12 and it's needed because of latest changes in redirection code handling. Noticed while reviewing https://git.reviewboard.kde.org/r/116017/ (Dawit, you may want to rebase it if this goes in). Diffs - kio/kio/job.cpp 9cf2b57 Diff: https://git.reviewboard.kde.org/r/116048/diff/ Testing --- various Thanks, Andrea Iacovitti
Re: Review Request 116048: Remove Content-Type header when redirecting to GET
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/116048/#review50897 --- This review has been submitted with commit 03a400be489d32cd6e7f1eb14bfad69566db384d by Andrea Iacovitti to branch KDE/4.12. - Commit Hook On Feb. 25, 2014, 4:21 p.m., Andrea Iacovitti wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/116048/ --- (Updated Feb. 25, 2014, 4:21 p.m.) Review request for kdelibs and Dawit Alemayehu. Repository: kdelibs Description --- This fix is for stable branch KDE/4.12 and it's needed because of latest changes in redirection code handling. Noticed while reviewing https://git.reviewboard.kde.org/r/116017/ (Dawit, you may want to rebase it if this goes in). Diffs - kio/kio/job.cpp 9cf2b57 Diff: https://git.reviewboard.kde.org/r/116048/diff/ Testing --- various Thanks, Andrea Iacovitti
Re: Review Request 116048: Remove Content-Type header when redirecting to GET
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/116048/ --- (Updated Feb. 26, 2014, 5:57 a.m.) Status -- This change has been marked as submitted. Review request for kdelibs and Dawit Alemayehu. Repository: kdelibs Description --- This fix is for stable branch KDE/4.12 and it's needed because of latest changes in redirection code handling. Noticed while reviewing https://git.reviewboard.kde.org/r/116017/ (Dawit, you may want to rebase it if this goes in). Diffs - kio/kio/job.cpp 9cf2b57 Diff: https://git.reviewboard.kde.org/r/116048/diff/ Testing --- various Thanks, Andrea Iacovitti
Review Request 116073: Do not use encoded URL when creating relative symlinks
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/116073/ --- Review request for kdelibs and David Faure. Bugs: 330463 http://bugs.kde.org/show_bug.cgi?id=330463 Repository: kdelibs Description --- When creating symlinks in KNewFileMenuPrivate::_k_slotSymLink, call prettyUrl() instead url() to retrieve the user entered text. Otherwise, a percent encoded version of the URL will be used to create the symlink which of course results in the creation of an invalid symlink. Note that this call needs to probably be changed toString() in kf5 since it is using QUrl. Diffs - kfile/knewfilemenu.cpp e7fe237 Diff: https://git.reviewboard.kde.org/r/116073/diff/ Testing --- Follow the steps outlined in the bug report to create a symlink to a file whose path or name contains characters that are not allowed in a URL. Thanks, Dawit Alemayehu
Re: Review Request 116073: Do not use encoded URL when creating relative symlinks
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/116073/#review50899 --- Hmm, KUrl isn't very good with relative urls indeed. This fix is incomplete: a symlink to a path with a % in it would still lead to %25. The Qt5 fix is obvious: toString(QUrl::FullyDecoded). But in kdelibs4/qt4, I can't find a good solution. path() truncates at a '#', so no go either. Ah, I found it... QUrl(kurl).toString() :-) The method I always declared completely wrong (for not encoding '#' in paths, breaking round-tripping) finally has its usefulness... (for the case of relative urls, rather rare in KDE code). I just committed a unittest extension to kurltest.cpp in KDE/4.12 which proves all this :) - David Faure On Feb. 26, 2014, 6:31 a.m., Dawit Alemayehu wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/116073/ --- (Updated Feb. 26, 2014, 6:31 a.m.) Review request for kdelibs and David Faure. Bugs: 330463 http://bugs.kde.org/show_bug.cgi?id=330463 Repository: kdelibs Description --- When creating symlinks in KNewFileMenuPrivate::_k_slotSymLink, call prettyUrl() instead url() to retrieve the user entered text. Otherwise, a percent encoded version of the URL will be used to create the symlink which of course results in the creation of an invalid symlink. Note that this call needs to probably be changed toString() in kf5 since it is using QUrl. Diffs - kfile/knewfilemenu.cpp e7fe237 Diff: https://git.reviewboard.kde.org/r/116073/diff/ Testing --- Follow the steps outlined in the bug report to create a symlink to a file whose path or name contains characters that are not allowed in a URL. Thanks, Dawit Alemayehu
Re: Review Request 116073: Do not use encoded URL when creating relative symlinks
On Feb. 26, 2014, 6:47 a.m., David Faure wrote: Hmm, KUrl isn't very good with relative urls indeed. This fix is incomplete: a symlink to a path with a % in it would still lead to %25. The Qt5 fix is obvious: toString(QUrl::FullyDecoded). But in kdelibs4/qt4, I can't find a good solution. path() truncates at a '#', so no go either. Ah, I found it... QUrl(kurl).toString() :-) The method I always declared completely wrong (for not encoding '#' in paths, breaking round-tripping) finally has its usefulness... (for the case of relative urls, rather rare in KDE code). I just committed a unittest extension to kurltest.cpp in KDE/4.12 which proves all this :) Great! Always fan of unit testing to prove stuff out. I will change the patch to use QUrl(kurl).toString() then. - Dawit --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/116073/#review50899 --- On Feb. 26, 2014, 6:31 a.m., Dawit Alemayehu wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/116073/ --- (Updated Feb. 26, 2014, 6:31 a.m.) Review request for kdelibs and David Faure. Bugs: 330463 http://bugs.kde.org/show_bug.cgi?id=330463 Repository: kdelibs Description --- When creating symlinks in KNewFileMenuPrivate::_k_slotSymLink, call prettyUrl() instead url() to retrieve the user entered text. Otherwise, a percent encoded version of the URL will be used to create the symlink which of course results in the creation of an invalid symlink. Note that this call needs to probably be changed toString() in kf5 since it is using QUrl. Diffs - kfile/knewfilemenu.cpp e7fe237 Diff: https://git.reviewboard.kde.org/r/116073/diff/ Testing --- Follow the steps outlined in the bug report to create a symlink to a file whose path or name contains characters that are not allowed in a URL. Thanks, Dawit Alemayehu
Re: Review Request 116073: Do not use encoded URL when creating relative symlinks
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/116073/ --- (Updated Feb. 26, 2014, 7:19 a.m.) Review request for kdelibs and David Faure. Changes --- Updated patch. Bugs: 330463 http://bugs.kde.org/show_bug.cgi?id=330463 Repository: kdelibs Description --- When creating symlinks in KNewFileMenuPrivate::_k_slotSymLink, call prettyUrl() instead url() to retrieve the user entered text. Otherwise, a percent encoded version of the URL will be used to create the symlink which of course results in the creation of an invalid symlink. Note that this call needs to probably be changed toString() in kf5 since it is using QUrl. Diffs (updated) - kfile/knewfilemenu.cpp e7fe237 Diff: https://git.reviewboard.kde.org/r/116073/diff/ Testing --- Follow the steps outlined in the bug report to create a symlink to a file whose path or name contains characters that are not allowed in a URL. Thanks, Dawit Alemayehu
