Hey folks, Back in December, the localization tool used for Spacewalk changed from Transifex to fedora.zanata.org, along with everything else Fedora-related. At that time, the initial load of the SW L10N files was done for us by the folks in Fedora-infrastructure.
The way Spacewalk is built, we have two kindsOf localization technologies in play. For the web-UI, we have XLIFF files (look for StringResource_en_US.xml for an example). And for the backend and clients, we use gettext's .po files. As a result, when our project was moved from Transifex, it was created in fedora.zanata.org as the 'spacewalk' project, with two 'versions' - 'spacewalk-frontend' and 'spacewalk-other'. The problem with this, is that those really aren't versions, those should be separate *projects*, which are *versioned* as spacewalk releases are cut. To manage translations, what we should have is a spacewalk-frontend and spacewalk-other project, inside of which there is one version for each SW release. The process, did we have such a setup, would be something like this (to match the code-release process): Project: spacewalk-frontend Version: master <-- All changes get pushed here Version: 2.3 <-- State of translations as of the release of 2.3, plus backported chgs if any Version: 2.2 <-- State of translations as of the release of 2.2, plus backported chgs if any ... Translations/new sources being made for the next release are pushed into version-master. When it became time to release 2.4, the most-current-state of translations would be pushed into spacewalk-frontend with a version of 2.4. I'd like to get this unravelled as part of the upcoming SW2.3 release. Anybody on the list have thoughts on this, or major objections? Let me know please! Thanks, Grant -- Grant Gainey Principal Software Engineer, Red Hat Satellite _______________________________________________ Spacewalk-devel mailing list Spacewalk-devel@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-devel
