Re: What about use xml for descriptions of packages?
First of all, I did not get it in my first reply that you spoke from a
translaters point of view. I just have a very limited view on
translation work, so my arguments may not be correct.
Am Sonntag, den 25.05.2008, 16:05 +0200 schrieb Fernando Cerezal:
> How can a program know if
>
> * A description sentence with
> two lines
>
> and
>
> * A description sentence with
> two lines
>
> are the same?
As always: by definition. If you define that indentation matters, first
one would be treated as two lines and the second as one. If you define
that indentation does not matter and bullet points have to be seperated
by an empty line (I think POD does something like this), then the first
entry is one line. So the problem is a missing definition of how the
formating should be treated by a parser, not a new document format.
> Or other similar problem: The url of project web page changes, like this:
>
> Upstream URL: http://www.example.com
> Upstream URL: http://www.example.com/project
>
> This is handled like a modification of the translation, and a
> translator for every language needs to review that, and «translate»
> it.
For this case, the Homepage field exists. By using that, the Description
does not need to be touched in any way.
> The problem is that the number of descriptions translated grows lower
> than the number of packages, and besides this, the translators have to
> review older descriptions that have not new information, but change of
> format, change of URLs and so on.
I see the burdon that it brings to translators but I do not understand
how XML may resolve those. URL should IMHO not be in the description as
they are subject to change and a better alternative exists. If the
format changes, the problem is to detect whether it is a "real" change.
Checking for changes in whitespace are equally easy to detect in the old
and an XML-based format. If new points are added to list or a point is
split into two, you can not automatically detect and correct those in
either format.
> I think using XML, or HTML, and embed a tiny web browser into
> synaptic, we can resolve part of the problem for translations and use
> the benefits of HTML, like including images, real links for web pages,
> links between packages that can be "easyly" handled.
I'm still not convinced that these features have a benefit.
> I write XML because is something I know. I mean markup tags.
This is valid but I think there are better markup languages for that
purpose that do not effect the readability of the document. Also, a lot
of parsers for these language exists and they are easily transformable
into other formats, such as (X)HTML.
> The descriptions have a lot of lists, execute strings, urls, and so on.
> If an item of a lists changes, we have to review all the list, find
> the change, do it in the translations and send it to revision process.
How does XML prevent a review here?
> There is no convention with this [Homepage field]. Or if there is, it is not used.
There is. If it's not used, you can file wishlist bugs.
> > I still do not see why the current scheme is limited. Can you give
> > examples where special markup or links in the texts may be useful?
>
> lists, links, non-translatable strings (URLs, numbers of version),
> changes in tabulation...
All such things are covered by more readable markup languages, too. I
agree that lists are a problem with the current format.
> Perhaps my question is bad presented and it introduces noise to the
> list. I'm sorry so.
I do not think so. As said, at least I did not see that you spoke from a
translator's point of view at first.
Best regards
Manuel
Reply to: