1 |
Pacho Ramos wrote: |
2 |
> > So, rephrasing the example Alexandre pasted, consider: |
3 |
> > |
4 |
> > x11-libs/qt-core - The Qt toolkit is a comprehensive C++ application |
5 |
> > development framework. |
6 |
> > |
7 |
> > vs. |
8 |
> > |
9 |
> > x11-libs/qt-core - A comprehensive C++ application development framework |
10 |
> > |
11 |
> > Which one is better, in your opinion? |
12 |
> |
13 |
> Well, I my case I would prefer second |
14 |
|
15 |
I agree, I also like the second example. |
16 |
|
17 |
|
18 |
> sentence... |
19 |
|
20 |
http://en.wikipedia.org/wiki/Sentence_(linguistics)#Major_and_minor_sentences |
21 |
|
22 |
Suggests that even a phrase such as the second example above can be |
23 |
called a (minor) sentence. |
24 |
|
25 |
|
26 |
> but it would still end with a dot. |
27 |
|
28 |
I think that looks ugly and is redundant. |
29 |
|
30 |
Especially if we were to require that all DESCRIPTION phrases must |
31 |
always be presented with a full stop, I think it is a very bad idea |
32 |
to enforce that they are written into the ebuilds. Especially if |
33 |
there is a rule that they will always be terminated by a full stop |
34 |
then that should and must be added by tools using the ebuild. |
35 |
|
36 |
It makes absolutely no sense to have so frequent redundant data in |
37 |
ebuilds, and it seems like full stop or no full stop is a matter of |
38 |
presentation policy and should thus happen during presentation. |
39 |
|
40 |
|
41 |
> But if it sounds rare for you, no problem. |
42 |
|
43 |
ebuilds are markup and not formatting IMO, and the two shouldn't be |
44 |
confused. If you want to work on presentation (which is important |
45 |
too!) then go for it, but in any case I don't think a full stop at |
46 |
end of descriptions is really worth the cost. All user interfaces are |
47 |
shitty enough already, and users are unable to deal with information |
48 |
already, so please don't add redundancy like full stops would be to |
49 |
the problem. |
50 |
|
51 |
|
52 |
//Peter |