|Summary:||Please make redhat-switch-mail use intltool|
|Product:||[Retired] Red Hat Linux||Reporter:||Christian Rose <menthos>|
|Component:||redhat-switch-mail||Assignee:||Ngo Than <than>|
|Status:||CLOSED RAWHIDE||QA Contact:|
|Fixed In Version:||Doc Type:||Bug Fix|
|Doc Text:||Story Points:||---|
|Last Closed:||2003-08-18 08:15:21 UTC||Type:||---|
|oVirt Team:||---||RHEL 7.3 requirements from Atomic Host:|
|Cloudforms Team:||---||Target Upstream Version:|
|Bug Depends On:|
Description Christian Rose 2003-02-04 17:38:01 UTC
Please consider making redhat-switchmail use intltool. This will significantly ease the translation of the .desktop file entries for translators, since they can be translated and maintained directly from the po file.
Comment 1 Christian Rose 2003-02-04 18:03:58 UTC
Using intltool solves many problems that are present when managing and editing translations of message entries in .desktop files (and files in many other non-code file formats) directly. Below I'll use .desktop files as the example, but all of this applies to all the other non-code file formats that intltool supports. intltool integrates the message entries in .desktop files into the application's normal pot file, and then later merges back the translations into the .desktop file at build time. By using this strategy, it solves the following important problems: * Trackability. With intltool, the status of completeness of .desktop entry translations is tracked together with the rest of the application status on for example translation status web pages. With direct .desktop manipulation, the status for these translations has to be kept track of seperately (and usually isn't kept track of at all). * Visibility. With intltool, the .desktop entries to translate are immediately visible to the translator as any other message at the same central place as the other messages (the .po files), and so it's close to impossible for the translator to forget these messages. With direct .desktop file manipulation, this danger on the other hand is exceptionally big as each and every application names its .desktop files differently and places them differently, and sometimes there are many .desktop files in the same application and sometimes there are none -- impossible to easily keep track of when you handle the translations of a large number of applications. * Notification. With intltool, changes and additions to the .desktop entries propagate directly into the potfile, and gets marked the same way as other message additions and changes, and hence, the translator gets notified of changes. With direct .desktop file manipulation, changes in the original aren't tracked or marked and so messages may easily have incorrect translations forever. * Translation re-use. With intltool, the messages benefit from the translation re-use that's used in po files. The exact same message that's used in the .desktop file and somewhere else in the application does only need to be translated once. Also, similar messages get appropriately fuzzy-matched, so the translator does only need to make the appropriate changes, not translate the whole thing again. * Stability. With intltool, each translator does only edit his or her .po file. With direct .desktop file manipulation each and every translator needs to edit the same file, which may result in problems with different encodings used, and other such accidents that ruin all translations. Also, there isn't the same danger of cvs conflicts or file access conflicts.
Comment 3 Ngo Than 2003-08-12 10:30:56 UTC
it's renamed in RHL 9. the correct name is redhat-switch-mail.
Comment 4 Ngo Than 2003-08-18 08:15:21 UTC
it's fixed now in 0.5.20-1 or newer.