Code review comment for lp:~dpm/ubuntu-calendar-app/rename

> Al 12/06/13 18:49, En/na Olivier Tilloy ha escrit:
> > So if I understand your code correctly, you’re injecting the "i18n.tr()"
> calls into a temporary copy of the desktop file.
> Yeah, more or less. I'm extracting the translatable strings from the
> .desktop file and putting them into a temporary .js file, which I then
> feed to xgettext. I'm essentially mimicking the behaviour of intltool
> when dealing with .desktop files: it extracts the strings, puts them in
> a temporary .h file and then adds this file to the list of files for
> xgettext to process.
>
> The only difference is that I've made this temp file a valid .js file
> instead of a C .h file.
>
> > To mimick closer what we’re doing for the core apps using cmake, what about
> doing the reverse, i.e. having the calls to i18n.tr() already in a desktop.in
> file, and generating the desktop file from there by removing the calls to
> i18n.tr()? This would make for a more flexible solution, if in the future we
> need to translate more strings in the desktop file.
> The difference in the community core apps is that essentially we're not
> using a build system. I've simply added a .pro file so that we can
> execute qmake to update the .pot file, but the rest of the files don't
> need any build step.
>
> If I modify the .desktop file to include i18n.tr() calls, I'll be adding
> a step whereby before running any of the apps, they will need to be
> built to generate the .desktop file from the .desktop.in file. Which
> will probably need to have another .pro file at the top of the source tree.
>
> I wanted to make the change as unintrusive as possible, and keep the
> .desktop file untouched. In this way:
>
> - Apps are run as before and don't need a build step
> - To update the .pot file one can just run 'qmake && make pot' from the
> po/ folder
>
> At some point, we'll probably need to standardize on the same build
> system across all apps, which I guess will be CMake. At that point,
> we'll also be standardizing on the way we extract .desktop translations,
> and the qmake rules will need to be changed in any way. But we're not
> there yet, and to me (for the qmake-based apps), .desktop file
> generation would bring drawbacks at this point.
>
> I hope that makes sense.

That makes complete sense, thanks for the detailed explanation. If this is the way intltool does it, then it’s definitely the way to go. And not requiring any additional step for running the app is a must-have too.