Re: Digikam-doc is old, [now] Lokalized screenshots
Hi Valerio, sorry for the delay,
On Sábado 13 Febrero 2010 11:17:38 usted escribió:
> Alle venerdì 12 febbraio 2010, José Manuel Santamaría Lema ha scritto:
> > Hi Valerio,
> >
> > Mark have uploaded an updated digikam-doc to unstable, however note
> > that while your italian *.po files are 100% translated (thank you
> > for your work), there are no localized screenshots for italian, even
> > there are some screenshots from the KDE 3 old days in english.
> >
> > If you have enough spare time, you might want to help in upstream
> > with this problem; if this is the case, ask your coordinator how to
> > proceed.
>
> Realizing screenshots is really time consuming and is less useful than
> translating GUI and Docs, anyhow, now that I only need to maintain
> documentation, since only small changes are introduced upstream, I will
> quickly start this work.
Thank you for caring :)
> If every translator is going to localize the screenshots (.png format)
> of digikam-doc as I hope, then you will face an increase in digikam-doc
> size. It's just a modest proposal, but what do you think about splitting
> documentation in single packages like
> etc. and have digikam-doc as meta-package which installs the proper
> localized version considering environmental variables? Is it feasible?
Well, having a metapackage which installs a localized version depending on env
variables is not feasible. Note that none of the debian packages that I know
works that way, for instance for kde-l10n-xx you should install just the
translations you're interested in.
About splitting the package producing digikam-doc-es, digikam-doc-de, digikam-
doc-it and so on:
yes, it's feasible; however if a new translation appears, the package would need
to enter the NEW queue because the new translation would produce a new binary
package. It's not good idea to force the people who manage the NEW queue to
waste their time, so if it's really neccesary to split the package I would do
when the number of translations would be somewhat constant in order to avoid the
NEW queue as much as possible.
>
> Valerio
>
Reply to: