Hi Osma, > The problem I see w.r.t. merging with Debian is that the DDL translations > are all bundled into a separate package, which then overrides message > files and other language-specific resources in the original Debian > packages. For example, the message file > /usr/share/locale/fi/LC_MESSAGES/gcompris.mo is, according to dpkg -S, > originally present in gcompris-data, but overridden by > doudoulinux-l10n-fi-updates. There is thus no real integration with the > original deb package (gcompris-data in this case), so it is not entirely > trivial to create a patch against the original Debian source package.
Yes, we'd need a specific tool that reassembles translations for a given package, not for a given language as we're currently doing. The current way of doing is the view for translators, not packages. > I think I can understand why you have set up things this way, as it > probably makes translations much easier to manage than having to > manipulate the language files in each Debian source package separately and > then recompiling the full packages. Here is the full story :). In the beginning of the project, I tried to patch several Debian packages to include language updates. Although I succeeded in it, it has shown to be harder than expected because each package may use a slightly (or not) different way to include new PO files in the package. As I don't know much of the series of auto* tools (autoconf, automake, etc.), as these tools may change a lot between versions, in the end, a package I could recompile one day would suddenly not get compiled again later. Moreover, doing so, you need to track package updates from Debian to avoid your own packages be replaced with newer ones without our translations. Unless we have tight relations with Debian, which was far not the case in these old days :). So quite quickly I decided to overwrite translations directly on the Live DVD, during the Live build process, which allowed us to increase the number of resources on Transifex to around 75 without any major difficulty. Later I discovered that a package can “divert” files from another package, this is an official feature of Debian packages. So when we decided to move all the tricks performed during Live build into Debian packages (because of ARM), I decided to create l10n packages instead of patching applications packages– it would have required too much time, really. > Now if we take the creation of patches against original Debian source > packages as a goal (as suggested recently on the debian-jr mailing list), > I think it can be achieved in two different ways: > > 1. Switch to a process where translations are maintained by modifying the > original source packages, which are then recompiled for DDL. Creating > patches for upstream Debian packages would then be trivial. > > 2. Keep the current model of doudoulinux-l10n-* packages, but write tools > that merge the DDL specific language files (.po etc) back into the Debian > packages so that patches can still be generated. > > I think neither way is easy, but 1. might be entirely unrealistic? Yep! Unrealistic, maybe not, but time greedy, surely! You'd need to analyze each of the 75 source packages in order to determine how translations are included and compiled. There is a high risk that this work is 100% manual and I fear that you spend a lot of time when new languages need to be included or new packages are integrated, or even when new versions of packages come. That said I agree to say that 1) is the easiest way to get our translation work directly into official Debian packages. But on the other hand, if we want our translators to be able to quickly see their changes in DDL, 2) is probably the best alternative, otherwise we would need to recreate a Debian infrastructure to get our patched packages automatically built during nights. Plus translators can more easily make their own l10n packages if they want to (if their cannot access Internet regularly–it happens– or are very impatient to see their work live). Finally I don't think 2) excludes 1) or the reverse, these are just different ways to assemble our work, because different audiences have different needs. Of course doing both would require more maintenance. As said above, we likely need to keep 2) and provide a part of 1) though. I suggest as a start that, instead of producing patches for the Debian packages, we just provide diff'es of PO files (per package) that the package maintainer would then have to manually merge into its package. He knows his package better than us and thus this can be the way that requires least time globally. Let's progress step by step! > There's also the problem of differing software versions in DDL / Debian > sid / upstream, which may create interesting merging issues, but I haven't > thought of that in detail. This is a real issue in my opinion. Supposing we provide diff files for PO files per package, I'm not sure upstream authors would be able to easily use them because of the merging issue. We should instead diff to the HEAD version of each package, which requires us to find the translation repository of each project. Note that I do my best to only use PO or TS files. This should lower the effort to find a reliable way to merge these files for various versions of the same software. The issue currently exists for Debian too. If we ignore the fact that we're currently late with respect to the Debian schedule (oh yes, DDL 2.x is stil based on oldstable!), anyway, DDL will always be based on stable, not testing nor unstable–it's quite obvious. Translators will then want to improve translations for stable, the version they have at home. I'm not sure Debian developers will want to spend time in updating translations for stable. I had even understood that, unless a security issue is found, packages in stable are never patched! Even bug fixes rarely find their way for a package update in stable :(. So in short: it seems we need a smart tool to perform PO/TS file merging and diff'ing, whatever the target audience (Debian or upstream). > Also I have not looked closely at the merging > capabilities of Transifex, except that some details of the merging process > seem problematic from the point of view of having different versions of > the original software. If you push translations for an older software > version than what is currently in Transifex, some messages may be lost if > you're not careful. At least that's how I read the description of the > --source argument of transifex-client: > http://support.transifex.com/customer/portal/articles/996211-pushing-new-translations > > What do you think? I'd say avoid playing with Transifex for merging PO files! We have no control over its source code. Something that could work one day could be broken later. I think it's better to use it the simplest possible way. -- Cheers, JM.
signature.asc
Description: This is a digitally signed message part
_______________________________________________ Doudoulinux-lang mailing list [email protected] https://mail.gna.org/listinfo/doudoulinux-lang
