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.