guidelines
mattetti
today and everyone (me included) thought that a hard limit at 80chars
per line doesn't make much sense.
I agree we should have one sentence per line but I'm fine with people
using 100 chars on a line as long as it doesn't get crazy.
What do you think?
- Matt
Rich Morin
> I don't want to start a fight or anything. But I talked
> to few people today and everyone (me included) thought
> sense.
>
> I agree we should have one sentence per line but I'm fine
> with people using 100 chars on a line as long as it doesn't
> get crazy.
>
> What do you think?
80 is arguably better than 100, in that it meshes better with
printing software, etc. I could also point out a number of
software projects that specify 80 characters as the limit.
That said, I'm OK with loosening it up to 100 characters, if
that makes folks more comfortable. Anything over that starts
to force folks into line wrapping or horizontal scrolling on
all but the widest screens.
-r
--
http://www.cfcl.com/rdm Rich Morin
http://www.cfcl.com/rdm/resume r...@cfcl.com
http://www.cfcl.com/rdm/weblog +1 650-873-7841
Technical editing and writing, programming, and web development
Dale Campbell
relic of older terminals and lower resolution monitors, where space
was more of an issue than it is today. I guess it just kinda stuck
around as the 'standard' line length (for developers, at least; not
sure what happens in the printing world). Raising that to 100
characters is cool with me. :)
Rich Morin
> Correct me if I'm wrong, but I believe the 80 character limit
Actually, it dates from IBM's 80 column punch card format:
http://en.wikipedia.org/wiki/Punch_card
Many early terminals emulated this line length, for obvious
reasons. Typesetters commonly prefer lines with even fewer
characters, because they are easier to read.
Damir Zekić
> reasons. Typesetters commonly prefer lines with even fewer
> characters, because they are easier to read.
Well, it's still emulated - it's the default width of every terminal
client today (including Terminal.app) and hence the default width in
Vim (even gVim under Linux/Win). I prefer to limit my line length to
80 so that no lines were auto-wrapped which screws up the line
navigation in the editor.
That said, I don't use Vim that much anymore but for compliance
reasons have set the margin in TextMate to 79 characters (80th one
shouldn't actually be used :)). So I like the 80 chars limit, but
won't insist on it.
--
Damir Zekić
http://twitter.com/sidonath
Joaquin Rivera Padron
- git log does not show lines longer than my terminal, so it becomes difficult to trace git diffs with english versions for a start. (this is the most important drawback)
- also, when you unmaximize emacs 80 lines fit right in the editor
I know it is a pain to cut lines in 80 everytime an edition occurs, but macros should be available to break lines around-lesser 80
but anyways it's a loose opinion of mine, cheeers
joaquin
At 00:00 -0800 12/10/08, Dale Campbell wrote:
> Correct me if I'm wrong, but I believe the 80 character limit
> is a relic of older terminals and lower resolution monitors ...
Actually, it dates from IBM's 80 column punch card format:
http://en.wikipedia.org/wiki/Punch_card
Many early terminals emulated this line length, for obvious
reasons. Typesetters commonly prefer lines with even fewer
characters, because they are easier to read.
Arthur Zapparoli
Why? I think it's better to cut the line exactly the same word at the
english one. It's better to review translations and diff content with
the English one.
Arthur Zapparoli
http://merb-br.org
http://arthurgeek.net
Ilya Bruklich
--ilya
Rich Morin
> I guess the 80 chars limit don't make sense for translated content.
>
> Why? I think it's better to cut the line exactly the same word at
> the english one. It's better to review translations and diff
> content with the English one.
As a monolingual (more or less) person, I don't have much expertise
here. I won't let that stop me, but please correct me if I get
anything wrong. :-)
Most written languages have words, phrases, sentences and paragraphs.
The correspondence between documents in multiple languages will tend
to increase in that order. That is, word-based correspondence is
likely to be fairly rare, and even phrase-based correspondence may
not exist, but corresponding sentences and paragraphs should be easy
to find (and compare) in most cases.
So, expecting lines to break at a corresponding word doesn't make
much sense. However, breaking lines at sentence boundaries still
makes sense. Also, it shouldn't be too hard to break most sentences
at phrase boundaries, to make the internal structure clear.
I don't think there will be much diffing of corresponding files,
because the diff code would have no way to figure out which lines
(etc) match up. If we wanted to make this possible, we could add
"positional markup" to help in matching up corresponding material.
The current software passes HTML comments on to the output, but
(curiously) ignores anything _after_ an HTML comment in the same
line. So, these both disappear when the book is formatted, but
only the HTML comment shows up in the "View Source":
<!-- This passes into HTML --> This disappears.
I wouldn't be in favor of adding this sort of markup unless it
has a strong purpose, however, as it would make the source code
significantly harder to read and edit...
Ted Han
I don't think that we should expect that there is a sentence level
correspondence.
Pages should have more or less the same propositional content (i.e.
the pages talk about the same thing, with more or less the same
perspective), but the way that content is structured may be different.
Remember that you have things like nested clauses in sentences which
will be in wildly different locations depending on if you're a Subject
Verb Object language (english) vs a Subject Object Verb language
(japanese). German's even weirder :)
Also remember that we're talking about a book. The formatting should
be done either by a PDF renderer or by a web browser. I think the
80-100 line cut off is really a convenience for people editing. And
TBH, i soft wrap, so i'm some what taken aback by the fact that we're
concerned about the subject at all.
Git's not a content editor. The reason why git works is that it does
line by line diffing. If you're doing line by line editing (short of
changing code samples), you're probably wreaking havoc on the
structure of the paragraph the sentence is in. Don't let Git dictate
the way you edit. This is a book, read, write and edit it like a
book.
I don't know what to say about the macro issue. I think it's a bit on
the crazy side to have macros that are sensitive to line number
(again, excepting code samples), i mean... that's the whole point of
HTML anchors right?
Hope that helps throw some more info into the question... what do you
guys think?
-Ted
On Wed, Dec 10, 2008 at 12:34 PM, Rich Morin <r...@cfcl.com> wrote:
>
> At 14:41 -0200 12/10/08, Arthur Zapparoli wrote:
>>
>> Why? I think it's better to cut the line exactly the same word at
>> the english one. It's better to review translations and diff
>> content with the English one.
>
> here. I won't let that stop me, but please correct me if I get
> anything wrong. :-)
>
>
> Most written languages have words, phrases, sentences and paragraphs.
> The correspondence between documents in multiple languages will tend
> to increase in that order. That is, word-based correspondence is
> likely to be fairly rare, and even phrase-based correspondence may
> not exist, but corresponding sentences and paragraphs should be easy
> to find (and compare) in most cases.
>
> makes sense. Also, it shouldn't be too hard to break most sentences
> at phrase boundaries, to make the internal structure clear.
>
>
> I don't think there will be much diffing of corresponding files,
> because the diff code would have no way to figure out which lines
> (etc) match up. If we wanted to make this possible, we could add
> "positional markup" to help in matching up corresponding material.
>
> The current software passes HTML comments on to the output, but
> (curiously) ignores anything _after_ an HTML comment in the same
> line. So, these both disappear when the book is formatted, but
> only the HTML comment shows up in the "View Source":
>
> <!-- This passes into HTML --> This disappears.
>
> I wouldn't be in favor of adding this sort of markup unless it
> has a strong purpose, however, as it would make the source code
> significantly harder to read and edit...
>
Carlo Pecchia
>
> I don't think that we should expect that there is a sentence level
> correspondence.
>
>
> This is a book, read, write and edit it like a book.
I agree completely.
--
Carlo Pecchia
email: c.pe...@gmail.com
Rich Morin
> ...
> Git's not a content editor. The reason why git works is that
Indeed. And by starting each sentence on a new line, we allow
Git to show Matt (and other editors) which sentences they need
to consider. If Matt has to wade through an entire paragraph
and try to spot the changed parts, he will take longer and may
miss problems.
Alx
Simple explanation: I (personnally) find it more comfortable
to read long blocks of text this way. And after a few hours of
translation, it surely come nicely on my eyes tiredness :)
it's just coming from a design tips Ive read few years ago:
http://www.netmechanic.com/news/vol2/design_no4.htm
It's explaining is more confortable reading columns you've got
in newspapers than larged-width text blocks.
Just my bit to support the char limit ;)
Alex