Comments you submit will be routed for moderation. If you have an account, please log in first.

Opened 2 years ago

Closed 2 years ago

Last modified 22 months ago

#496 closed task (fixed)

Switch translation to use

Reported by: damato Owned by:
Priority: high Milestone: YAM 2.9p1
Component: translation Version: 2.9
Severity: minor Keywords:
Cc: OS Platform: All
Blocked By: Blocking:
Release Notes:

switched the whole catalog translation mechanism from manually submitting translated .ct files to the use of the free services of Now translators can freely use the services of and submit translations online via



Over the past years the number of maintained translations for YAM are constantly decreasing. While this might be perfectly correlated with the decreasing number of Amiga users/translators left, one can also argue that the way translations have to be performed and maintained is too complicated. Having to deal with subversion and change log entries might be one reasons. It is therefore desirable to evaluate alternatives to the current approach of directly editing the catalog translation files (.ct) which could be cumbersome and error prone as well as too complicated for some people not trained with them. Last not least the quality of the actually language translations of YAM are somehow unknown as today at most there is only one translator per language without any cross-checking mechanisms between translators in any form.

Background analysis

In recent years a free online service appeared on the internet ( which allows to not only provide a central place to deal with application translations. It also provides a nice and smooth online editor for editing all kind of translations with functionality like allowing to provide comments to potential translators, building groups of translators and even allowing to verify translations of each other. In addition, as is meant to be a community-driven translation service it has an increasing number of translation groups so that new fresh and Amiga-independent translators might even contribute to individual translations of YAM. It is therefore very attractive to consider switching to transifex rather than having to manually editing the .ct file and submitting it either via email to the yam developers or via directly checking in changes to our subversion repository. Furthermore, transifex also provides a python-driven command-line client which allows to directly pull and push translations from the command-line so that interaction between a repository checkin and transifex translations are possible.

Implementation recommendation

After analysis and testing of the only currently existing hurdle in directly switching to it is, that it doesn't directly support the Amiga-style catalog format. In addition, there doesn't seem to be a mechanism to even train or enhance transifex to use that format. However, as it supports a wide range of different translation file formats it also supports the probably most used format, the GNU gettext-based PO-style format for translations. While this format is currently not directly supported by e.g. flexcat it seems to be quite easily possible to develop conversion tools between these formats so that the transifex services can be used. The proposed procedure for switching to transifex is therefore:

  1. create a "YAM" transifex project with english language as the default language
  2. develop a conversion tool for converting between Amiga-style catalog description (.cd), catalog translation (.ct) and gettext-based PO-style template (.pot) and translation files (.po).
  3. convert all .cd and .ct files to corresponding .pot/.po files and upload them to transifex
  4. replace our .cd and .ct files in our source repository with corresponding .pot/.po files.
  5. modify the build Makefile to dynamically generate the .cd and .ct files from the .pot and .po files while building yam.
  6. setup an subversion<>transifex syncing mechanism so that changes on either side a propagated to the other service.
  7. notify our translator about the change and motivate them to directly use/register at instead.
  8. (optional): modify FlexCat to directly read PO-style translation files so that step 5 will not be required anymore.

The most critical point seems to be point 6 which should assure that if a translator prefers to directly editing the .po files in the repository these changes are directly uploaded to transifex. In addition, if changes are performed on transifex also the repository should be updated in regular intervals so that it is kept in sync.

Attachments (0)

Change History (5)

comment:1 Changed 2 years ago by damato

Please note, that as of today point 1-3 are already fulfilled:

  1. see
  2. see
  3. see transifex YAM project pages and widget at the bottom of page

comment:2 Changed 2 years ago by damato

(In [7452]) - added converted YAM.pot file to repository. This refs #496.

comment:3 Changed 2 years ago by damato

(In [7454]) * locale/*.po: added all converted .po files which will replace our .ct files

as soon as the makefile has been adapted to generate them on the fly.
This refs #496.

comment:4 Changed 2 years ago by damato

  • Resolution set to fixed
  • Status changed from new to closed

(In [7458]) * locale, src/Makefile: adapted the Makefile to generate the corresponding .cd

and .ct files on demand from the .po files. This finally fulfills the switch
to transifex and closes #496. However, documentation how to translate YAM
from now on is still missing.

comment:5 Changed 22 months ago by damato

  • OS Platform set to All
  • Release Notes modified (diff)

Add Comment

Modify Ticket

as closed The ticket will remain with no owner.
The resolution will be deleted. Next status will be 'reopened'.

E-mail address and user name can be saved in the Preferences.

Note: See TracTickets for help on using tickets.

This list contains all users that will be notified about changes made to this ticket.

These roles will be notified: Reporter, Owner, Subscriber

  • Jens Maus(Reporter, Participant)