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