Carlos E. R. wrote:
Hm. I have started translating for openSUSE, but have more experience with KDE. There we don’t have to be told there are changes, as there are *always* changes (i.e., daily). :) And for downloading the files, we only have to run ‘svn up’ to fetch all updated files. Using the project view in Lokalize, we can easily see which files have new or changed string (and can sort the files by the number of untranslated or changed strings). And the coloured diff in Lokalize makes it extremely fast and easy to see what parts of the English strings have changed (this is a godsend for multiparagraph strings!), and to update the translation accordingly. It’s both fast and efficient.
Well, lokalize, being a KDE program, is very well suited to the directory structure and procedure organization used by KDE, but apparently not so well to ours.
Ah, that’s true. I’ve been wondering why openSUSE has such a strange directory (and file naming) structure for translations. I would have guessed it was because it made things easier for the developers, but obviously it does not. Personally, for openSUSE translations, I use the the Pology summit workflow detailed at http://pology.nedohodnik.net/doc/user/en_US/ch-summit.html (but with a custom config file the Pology creator helped me with, since the openSUSE doesn’t use either of the two standard directory structures). The result is a standard directory structure for translation files (.po and .pot) files, just like for KDE, which means I can use the project viewer in Lokalize: ├── templates │ ├── activedoc │ │ ├── ad-blocks.pot │ │ ├── ad-contact.pot │ │ ├── ad-fields.pot │ │ ├── … └── langcode ├── activedoc │ ├── ad-blocks.po │ ├── ad-contact.po │ ├── ad-fields.po │ │ ├── …
We do have an svn server, but few translators use it. Many use an intermediate platform, vertaal, that is used mostly for organization (who translates what and when). It is this platform which emails the translator assigned to a file that it needs work. The details of this depends on each language team.
OK. I thought most translators still used SVN. Yes, using a Web platform certainly makes thing less efficient. (But if people prefer it, who am I to argue, as long as I can still use SVN.)
Plus other people have to retrieve the .pots, and after translation, submit the .pos to the devs. Typically they wait to do this till they think that all the translators have finished.
I didn’t realise this. OK, this I see as a big problem. Why would the .po files have to be *submitted* to the developers?
The devs are on a different server, git, I think. I guess there is not a single directory that has all the catalogs, but probably many, which is why they have to be collected by people for submission. This is a part of the process I don't see, so I don't know how exactly it works.
OK. In KDE, all applications *used to be* on a single SVN server. Now, they’re scattered across different (mostly Git) servers. But I believe they are automatically fetched when building (or perhaps only when packaging) the applications.
This is not unique to openSUSE. The Translation Project is also convoluted: translators are told of pending work by email, retrieve the file via http download, then submit back via email.
There is also a script one can use for this. But I agree that The Translation Project translations process could be more streamlined!
On other projects I participate (xine), I have to download the sources from packman, translate, then upload to a paste site that I can find (google drive, for instance), then post a link in an email to their mail list so that the devs them pick it.
That sounds terrible! Luckily, for most applications I have translated, I have been given commit access to SVN. Some require patches attached to bug trackers or sent to e- mail lists. These are also the projects with the fewest number of (updated) translations …
Convolution seems to be the norm; only some projects, like KDE, have it very well organized :-)
Yes, we’re lucky in KDE. :) -- Karl Ove Hufthammer E-mail: karl@huftis.org Jabber: huftis@jabber.no -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org