|
Bugzilla – Full Text Bug Listing |
| Summary: | translation patch for de, es, fi, ja, pt_BR | ||
|---|---|---|---|
| Product: | [openSUSE] openSUSE 10.3 | Reporter: | Forgotten User nqeDWc8OMK <forgotten_nqeDWc8OMK> |
| Component: | Translations | Assignee: | Karl Eichwalder <ke> |
| Status: | RESOLVED FIXED | QA Contact: | Karl Eichwalder <ke> |
| Severity: | Enhancement | ||
| Priority: | P5 - None | CC: | belphegor, carlos.e.r, elchevive68, forgotten_XG9X5w8kVa, noelamac, ro |
| Version: | Final | ||
| Target Milestone: | --- | ||
| Hardware: | Other | ||
| OS: | Other | ||
| Whiteboard: | |||
| Found By: | --- | Services Priority: | |
| Business Priority: | Blocker: | --- | |
| Marketing QA Status: | --- | IT Deployment: | --- |
| Bug Depends on: | |||
| Bug Blocks: | 351384 | ||
|
Description
Forgotten User nqeDWc8OMK
2007-12-26 11:20:44 UTC
Thanks a lot! Does this apply for lcn _and_ yast translations? Or, do you want me to prepare updates for both of them? I'd also like to add 'de'; 'de' is not 100% complete, but some strings were corrected lately. Yes, the 'es' translation of yast and lcn are both complete. We also did a full review of all messages, not only the ones we translated, for consistency and correctness. Only the 'update-desktop-files.es.po' is not completely reviewed, its so large (±50% reviewed). So, yes, we'd like a patch of both yast and lcn translations done, if possible. We understand the lcn part is not so simple, as it affects several programs, but perhaps it could be packaged separately as an optional rpm. As we commented in the mail list: +++ Date: Thu, 6 Dec 2007 15:15:53 +0100 From: Ladislav Michnovič Subject: Re: [opensuse-translation] translation-update 2007/12/6, Carlos E. R. <>: > The Thursday 2007-12-06 at 10:46 +0100, Karl Eichwalder wrote: > >> For LCN it would be harder, because the translations are distributed > >> in various packages. > > > > This could be done using the overload strategy with the shadow directory > > for the .mo files. We did those things for SLED10. The package name is > > translation-update. > > > > The tough part is to get rid of the package if you update from 10.3 to > > 11.0. > > Ouch. > > It has to be an optional package, with a warning to the user; and then try > to remind whoever does that in Yast development to remove the package on > upgrade... not a clean solution, it can backfire. I have an idea how to solve it. Create this package within Suse and do a proper numbering. For example 10.3.x.y, which shows, that it is connected to openSUSE Linux 10.3. Release translation updates as often as needed, but when next SuSE release comes, renumber it to 11.0.x.y and make this package empty. This package will come within installation media and it would be without any files, only README for some information. If somebody will do an update, YaST, zypper, rpm can handle this and will erase all files which was installed on the system by that package in previous version. One thing is needed, to make some dependency on some basic package or Pattern which will ensure, that this package will be always installed. Ask YaST2 maintainers for details. Regards Ladislav. ++- Another benefit is that releasing a translation patch will allow people to tell us what they find wrong in the translations when they use them; till them we have to few "eyes". If this procedure works well, we could use it to correct translation errors, too (even if it is via buildservice). (automated?) Of course, I can't talk for the other teams, but my feeling is they think the same. Yeap, we (pt_BR team) agree with Carlos! Thanks for the info. coolo, please approve the update request. Don't ask me, ask our coordinator SWAMPID is 15694 thanks patchinfo for yast-trans-* submitted as yast2-trans.patch.box patchinfo for the lcn part will follow. I also like to add 'fi' that features updated lcn translations. translation-update (lcn translation) submitted; patchinfo is translation-update.patch.box. Do I have to do something about this error message? Packages translation-update,translation-update-de,translation-update-es,translation-update-fi,translation-update-ja,translation-update-pt_BR are not contained in any product made from the distributions [I'm going to create a separate bug report for the update issue.) "are not contained in any product made ..." means: this is a new package and needs to be added to the product's maintained-data. done. the other problem is how to get the proper packages into the system, I've hooked these to the OpenOffice_org-$LANG packages for now: the patchinfo file now has this line: Freshens: translation-update-de OpenOffice_org-de,translation-update-es OpenOffice_org-es,translation-update-fi OpenOffice_org-fi,translation-update-ja OpenOffice_org-ja,translation-update-pt_BR OpenOffice_org-pt_BR meaning: additionally install translation-update-$LANG if OpenOffice_org-$LANG is installed. (In reply to comment #11 from Ruediger Oertel) > I've hooked these to the OpenOffice_org-$LANG packages for now: > > the patchinfo file now has this line: > Freshens: translation-update-de OpenOffice_org-de,translation-update-es > OpenOffice_org-es,translation-update-fi OpenOffice_org-fi,translation-update-ja > OpenOffice_org-ja,translation-update-pt_BR OpenOffice_org-pt_BR > > > meaning: additionally install translation-update-$LANG if OpenOffice_org-$LANG > is installed. Does that mean that the update will only be installed if OpenOffice_org is installed? What if the user doesn't have ooo installed? Why can't be hooked to a yast package? released Question: The file ...es/po/update-desktop-files.es.po was not included, I think, and Yast takes some of the translations from this file. Was it simply forgotten, or is there a problem? Yes, Yast, and there are quite a number of other things affected. First of all, if update_desktop_files is not updated, the packages built in the system won't have the new translations. About yast and the other affected items (menus, sidebars, ...) in the currently installed .desktop files, shouldn't some kind of update script be issued? Updating menu entries via update-desktop-files.es.po for release products is not an option, unfortunately, because it would mean that all affected package sould have to updated, too. |