Add a command to generate/refresh .pot and .po translation files

Now that quickly projects can include mallard help files (from quickly version 11.04) the proposed "quickly translate command [language]" should include the work flow for these also, if such a tool chain exists.

I agree, this is one area in which many application authors seem to struggle to get started, often needing the assistance of an experienced translator. It seems obvious that Quickly should reduce the burden here for new applications.

Right now I have to use the following workaround to refresh the .pot file, but without actually releasing the application:

$ quickly package
$ bzr revert debian/changelog

Since the packaging automatically updates the changelog, but I don't want to actually make a new release, the second line is necessary to revert this change.

Having a specific command would really be useful.

You should not that "quickly package" doesn't release your application. "quickly release" is doing that for you.

"quickly package", as the documentation intend, is only for you testing a packaged application of your app here. So what the use case to avoid "quickly package"? (an extra line in debian/changelog isn't hurtful and there is none added on "quickly package" starting natty).

It's all about the workfow, translating is different than packaging. Example:

I've developed a new functionality. Before committing the changes, I want to update the .pot translation template, so that the new strings are made available to the translators in Launchpad. Currently I need to execute the "packaging" workflow, which is not intuitive. Additionnaly, it displays eventual error messages about classes that are not found, asks me if I want to continue packaging, etc., all things that are not related to translations.

If we had a simple command that would refresh the .pot file (quickly translate?), we could for example put that as a bzr pre-commit hook, so that the translation template are automatically updated before each commit, ensuring that the translation available in Launchpad is always up to date.

It's good that before packaging, the translations get compiled, but you really want those new strings to be translated BEFORE packaging your application, otherwise this package is always containing not up-to-date translations.

Would it be difficult to implement such a command? The command should do 2 things:
- Update the .pot template by scanning all the files
- Compile the available .po files into .mo, so that the currently available translations show up in the program.

The difficult part is not to add a command but rather too end up with cluttering the user having too many commands (if it wasn't the case, I would have already end up with 30+ commands in ubuntu-application templates).

What you want to do is an extra step that opportunistic programmer shouldn't care about. They just want it to be refresh without having to ask for that. My guess is that it should be done for him without the developers has to explicitly ask for it. "quickly save" for hooking that in would make sense, isn't it? You added code -> you refresh what's impacted.

I still want to implement in the workflow the push/pull the translated code to launchpad automatically but not yet sure how to do that without a new command.

I understand your concern, and approve your goal to limit clutter for the user. If the templates got automatically updated when doing "quickly save", I would be happy (that's the same as what I was suggesting with my pre-commit hook).

This would also make the translation process more automatic for a lot of programmers that don't feel concerned with translations (mainly native English developers). Automatically updating the translation templates for them would be a good thing.

The automatic pulling of new translations from Launchpad could most probably be done in "quickly package". That way, when you create a new package, it automatically contains all the latest translations available from Launchpad. Since it's a command you would not execute several times a day (unlike "save"), I suppose the extra time needed to download the translations wouldn't be a problem. But the question is if that could be done automatically, not sure. Right now, requesting a package containing the translations is not instant, it gets generated and a link gets sent to you per email to download that, so I'm not sure you could do that directly from a quickly command... But this is off-topic regarding this bug, maybe we should create a new bug to track these ideas.

To come back to this story, would you then consider adding the translation template update mechanism in "quickly save"?

I totally agree with the fact that developers shouldn't bother about translations (and all my goal in not devoting a command for it is in that direction).

However, I think there is a little misunderstanding about what the commands are supposed to work, let me summarize:

quickly package -> this package current version for *you* to try it, there is no launchpad interaction and you don't need to setup your project in launchpad yet. I just produce a .deb for you to test on your system and should be use for local usage.

* quickly share -> share your current snapshot (alpha/beta) with friends. There is no bump in the versioning. It pushes the code to launchpad as well as a package (and create the packaging if you never created one before)

* quickly release -> do a proper release, bumping the revision *inside* your application (and not only the packaging), doing the packaging work for you if not already done, pushing the code and deliver it to your issues

So, you can:
$ quickly create ubuntu-application foo
$ quickly release

quickly package is totally optional in this workflow. You don't need it to "refresh" your package. Quickly release and quickly share are doing those steps for you.

Now, how to hook translations into that?
there is multiple steps: exporting the transations and importing them.
If you do that on quickly release -> it's too late, you export your translation to launchpad, but as you are making a new release, you won't import them anymore for *that* precise release.
On the contrary, systematically importing the translation on a release make sense as you want your users to have the latest and greatest of the translators work.

So, ok, import == release (I don't see much value to import during quickly share as it's just a snapshot, and even less with quickly package as it shouldn't interact with launchpad as I want to be able to build my project on the plane).

now export… if we want to automate that to launchpad, we want to export *before* making a new release, but we need also to connect to launchpad for that. That's a tuff question… quickly save will make sense as you change your code, but it also means that you maybe don't want to push your code to launchpad.

There is bug #688500 where we discussed on IRC about a "quickly sync" command when you work on multiple machine to ensure you always have the latest version of your code. This will use launchpad for synchronizing, so maybe the right place to put it? "syncing your code and your translation"? What do you think?

Thanks Didier, your explanations are clear.

I don't see where the problem would be to update the .pot file when doing `quickly save`. This would ensure that after each commit the .pot file is 100% synchronized with the source code. It's up to you if you want to push to Launchpad or not (additionally, why would you want to push translations that are not yet available in the source code that's on Launchpad?)

Launchpad would be able to retrieve the latest translations after a `bzr push`, if you have configured your project to automatically update the translations from your main Bazaar branch (which I always do)

Updating the .pot file on each `quickly save` does not imply any interaction with Launchpad, so you can continue developing your project on the plane ;) And doing it this way would mean that we don't need to create a new command just for that (as I understand you want to keep the number of commands low)

This is for the exporting part. Concerning the importing, I am afraid that this is not doable automatically. AFAIK you can only manually update the .po (either by merging the branch where you optionally export the translations, or by requesting an export [1] that will send you a link per email to a tarball containing all the .po/.mo files).

So my suggestion is to automatically do what can be done automatically (i.e. exporting on `quickly save`), and leave the importing to be manual. The compilation of the .po in .mo are currently done while packaging, or manually with `python setup.py build`.

Concerning `quickly sync` I don't personally see the need for it, since I always push my changes to Launchpad after a coding session, so when I use another machine I can just branch the project from Launchpad and I know it's complete. I am currently more concerned about the whole translation workflow (which potentially affect each Quickly project) than the smaller population of developers that switch machines all the time.

[1] https://translations.launchpad.net/quickly/0.x/+export