andr55 at laposte.net
Mon Oct 25 23:17:37 CEST 2010
Frank Griffin a écrit :
> Michael Scherer wrote:
>> So we need to find a better way.
>> Better in two points :
>> - better way to distribute it
>> - better way to translate it
> Maybe the problem is trying to use rpm as the management tool for
> Long, long, ago I had to write an order processing system for an IBM
> 5100, which supported 2 languages - APL and Basic - both of which were
> interpreted, meaning the source code had to fit into memory, which was 32K.
> This made it virtually impossible to comment the code in any meaningful
> way, since the comments took up memory needed for code.
> What I finally settled upon was to tag blocks of code with a 4-or-5
> character comment which was basically an index key into a typewritten
> document which contained the program comments. The same thing might
> work here.
> Change the rpm description to a database table partial key which
> corresponds to the package. Then set up a database table keyed by that
> partial key plus a language ID, and place the description in that
> language there. Change tools which display package descriptions to use
> the rpm value as a key into the database combined with the locale language.
> This shifts the space requirement from the package rpm SPEC to the
> database, and means that description maintainers can just have access to
> the database rather than the source tree. Since most uses of rpm don't
> make use of the description, bandwidth for normal maintenance goes
> down. For things like the install, you include a copy of the database
> on the media, or conditionally on the user's system for rpmdrake (much
> as they get to choose between hdlist and synthesis today).
> This would allow much more flexible queries, and would allow translators
> to extract all descriptions in their own language as a single result
> set, identify all packages which do not have a description in a given
> language, and so forth.
> If the central database were managed by JEE/EJB with role-based security
> tied to the new LDAP database, user maintenance would be fairly simple.
> Obviously, for use in captive form (e.g. in the install or on a user's
> system), an extract in some other form would be used to avoid the need
> for JEE.
> WDYT ?
Interesting idea. As I understand, descriptions are stored in local the
database of already installed packages, so this would be a pre-install
However there is the problem of keeping everything in sync, if the
documentation is not included in the rpms.
If in the development process the descriptions were kept in such a
central database, along with their localisations, they could be
automatically extracted from the database for insertion in the package
when the package is generated.
That won't reduce the size of the Rpms, but it would ensure that the
description, with localisations, is always included in the Rpm.
Since last minute changes before packaging are much less likely to
change displayed text (or documentation), the localisations risk being
up to date.
More information about the Mageia-discuss