Re: What about use xml for descriptions of packages?
2008/5/25 Manuel Prinz <firstname.lastname@example.org>:
> Am Sonntag, den 25.05.2008, 14:40 +0200 schrieb Fernando Cerezal:
>> I'm thinking about advantages and disadvantages of write the
>> description of the packages using XML.
> I like XML but it's a huge pain to write by hand. The current format is
> easy to read, easy to write and easy to parse. This is important and
> definitely not the case if it is XML.
How can a program know if
* A description sentence with
* A description sentence with
are the same?
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»
Sorry, perhaps XML is not the solution, but I prefer present a problem
with a possible solution than simplely the problem.
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 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 think using XML the descriptions can be rendered in different form
>> for text and graphical tools.
> If this something that is really needed, one could think about more sane
> such as allowing Markdown for Description field.
I write XML because is something I know. I mean markup tags.
> I thought about that
> for a while now but never really saw the need to have formatted text or
> code examples in a package description.
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.
> IMHO those just do not belong
> there. And for cases where links are needed, special fields as the
> Homepage field exists which are properly shown in most tools.
There is no convention with this. Or if there is, it is not used.
>> As disadvantage, we will need to develop a robot that do format for
>> the current descriptions and translations and we will have to review
>> all of them. Ciertainly, this will be an huge job.
> I'd rather convince people to adpot a new format, not to decide for them
> whether they want it or not. Change by evolution, not revolution.
I agree, I write to the list asking if there were any previous discussion.
>> However, I think the current scheme of descriptions is very limitied
>> and is better to do it earlier than translate more descriptions and
>> then move all to a new format in the future.
> 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...
And all other semantic issues and where form and content are mixed.
I don't know how is the backend of dpkg, but I know how is the
translator work and I think this thing could do the process more
Perhaps my question is bad presented and it introduces noise to the
list. I'm sorry so.
> Best regards
>  http://en.wikipedia.org/wiki/Markdown
> To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
> with a subject of "unsubscribe". Trouble? Contact email@example.com