[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: TDebs?

On 27/09/06, Otavio Salvador <otavio@debian.org> wrote:
Javier Fernández-Sanguino Peña <jfs@computer.org> writes:

> Maintainers (or translation coordinations), either for a translation-update
> only release in the sid or in the stable branch would upload updated .tdebs
> (along with some updaetd source files, which is the tricky part).

The most difficult part, looks to be, to build an update to
translation. To it, we would need to have an extra mode to rules to
allow us to build only the translation (as we have build-arch and
build-indep today), e.g build-trans...

This was discussed and overly discussedd in Extremadura :-)

The update (separated from the original source) would make sense only
for special cases - translation updates to stable branch, translation
updates to testing before release.

The main idea here was to have a initailly in the source package (as
we have now) the translations as po files. At build time .mo files and
all the binary localization data[*] will be placed in separate tdebs
for each language [**]. The regular package will no longer have any
localization information (maybe except po-debconfs translations, but
that is another issue and raises other issues - which were discussed,
also ;-) ) and the installation of tdebs will be done silently as an
automated dependency (apt needs to be patched) depending on the
languages selected, so that they are uninstalled automatically when
the package is removed.

Now, the tricky part, translation updates. The idea is to have a
separated source package which is generated from the original source
package which will generate the binary tdeb packages which have the
same name as the ones in the original source. These tdeb source
packages could be either created automatically with a tool which
should do the most best choices in most cases when creating the
package, or - until the need of a tool arises - by hand.

Creating the source package for tdebs could prove to be tricky in
cases where the localization info is more than simple po files or
binaries already translated (e.g.: voices' sound tracks in games), but
something more complicated which build during the build time of the
package - imagine build dependencies based on which the translation
compilation result changes, translations which are tightly bounded to
the binary.

Here is a simplified schema of the process:

OSP -> all binary debs
  |-----> a tdeb for each language for which localization material exists
  | (after release, via a tool or manually - depends on our needs)
TSP -> all the tdebs with bigger version number > OSP version

OSP = original source package
TSP = translation source package

Problem: there is stil the null-improvements update problem, but which
is not still better than the current situation. It could be argued
that an md5 sum can be computed on the source translation material and
confronted with the original md5-s in the previous version - but that
should be implemented in that tool, or later.

Note: Using tdebs instead of regular debs has the advantage of not
imposing some restricted namespace, separation of localization dpkg
information from the main information about packages.

[*] e.g.: ogg files with localized messages in a game, weird
localization information - found especially in games
[**] yes, there willbe an explosion of packages, but those will be
placed in different places in the archive, the /var/lib/dpkg/info
could have a /var/lib/dpkg/info/i18n/<lang_country> directory

"Imagination is more important than knowledge" A.Einstein

Reply to: