See also bug #105054

Just some info:

editplus:   ln 81  col 81
ultraedit:  Ln 81, Col. 81
Kedit: Line: 1  Col: 1

Note that ultraedit has the same letters as current gedit.

I don't think old heritage from what must have originated from old
terminal-based editors with a severe lack of ui space have much
relevance to todays situation with gui editors on high-resolution
screens and demand for brevity to accomodate for all users' needs.

I have tried to use "Line #, Column #" as you suggested but I don't
like it too much since it is too long and the real info (i.e. line and
column numbers) seems to "disappear" in such a long string.

I have changed it to "Ln #, Col #" as suggested in bug #105054

The GNOME Documentation Style Guide (GDSG) says the following about
abbreviations: 

"A shortened form of a word or phrase that takes the place of the full
word or phrase, for example Dr, a.m., p.m, etc. Usually abbreviations
are familiar and do not need any explanation." 

The GDSG doesn't say, but perhaps should say, that abbreviations are
usually used in the following circumstances: 

1. For convenience when dealing with commonly-used terms. 
2. For practical reasons where space is at a premium. 

Looking at gedit, I would say that the need to use the abbreviations
Ln, and Col, fall under the second category of requirement. Obviously,
we should spell out words wherever possible for clarity, but where
space is tight then a recognisable abbreviation should be permissible. 

Although Ln and Col are hardly in the same league as Dr or a.m. and
p.m., they are recognisable, at least in English. Do the Ln and Col
abbreviations cause a problem for localization? Would a line of
explanation in the gedit Help manual resolve this problem? 

Pat

There are several reasons why I think this is a bad idea.

First of all, "ln" and "col" aren't common enough abbreviations that
many non-English regular users understand them. For someone with
non-English background, getting used to English vocabulary is a large
task, and anything but the most common abbreviations usely end up low
in the priority list and order of learning.
"Dr" is an abbrevation that's common in many other languages (which
really is an exception compared to most abbreviations, that are highly
language-specific). "a.m."/"p.m." are language-specific but very
common in English language, so many users have learned its meaning,
although they are not familiar with such time references in their own
language. "Ln" and "col" are not familiar in the same way. Basically
the only place I have observed them is in some text editors.

Also, once in the past when I found out what these abbreviations meant
I asked other non-English and non-technical users what that
information at the bottom of the screen meant. Hardly anyone knew what
it meant, even less users used it, probably at least partly because of
this reason (the same applies to INS by the way). Because of this, I
believe that providing the full words will actually benefit many users
in that they will more easily know what this information represents
and be able to make use of it.

Secondly, what is said above also in almost all aspects often apply to
translators aswell. Translators are rarely English linguists but
rather experts in their own language. Thus, the danger of the
translators not understanding the abbreviations are often high, and
this can often cause these messages to be left untranslated or even
mistranslated.
Also, many abbreviations are ambigious and may have several possible
meanings depending on context (something that may be difficult for a
translator to distinguish between in a given translation), and many
don't translate well in that they don't have an equally well
established abbreviation in other languages, and thus use of
abbreviations may make the interface even more cryptic in localized
versions. This is why I don't recommend using abbreviations in the
first place in the developer guidelines for localization
(http://developer.gnome.org/doc/tutorials/gnome-i18n/developer.html#language).

Also, space clearly isn't an issue here. It's difficult to find any
other part of the interface where adding three extra characters would
have less effect.

Created attachment 15945 [details]
Screenshot of Swedish version

As a reference, above is a screenshot of the Swedish localization of
gedit, to show the space non-issue.

I agree with all of your points Christian. We should only shorten
words where space dictates we must, as a last resort. In Swedish there
isn't a problem with spelling out Rad and Kolumn, also there shouldn't
be a problem in English with spelling out Line and Column, especially
if we remove the comma, but there might be a problem in other
languages. 

Translators regularily make the choice whether a given translation is
too long (many languages are more verbose than English) and needs to
be abbreviated to fit. That's entirely up to the translator. This
would be no different from that, other than that there's plenty of
room in this case.
The issue in this case is the English original, as it is the basis of
all translations, whether abbreviated or not. It needs to be clear for
that reason, among other reasons outlined above.

Then unless Paolo can really make a case that the English version is
short of space, I have to agree with Christian. 

Ok. Paolo?

Looks like Paolo is not going to use full word in this case. Closing
as WONTFIX or?

That's up to him to decide.

I don't know if this is just me, but when I see the words Ln. and
Col., I'm thinking lieutenant colonel, even if the abbreviation is a
bit incorrect.

I personally vote for Line, Column,

The string freeze is comming near so what are we going to do ?

I agree with Christian and the others too. Spell it out when possible.

Created attachment 24037 [details] [review]
Proposed patch for unabbreviated versions

Are there any objections to committing this?

looking into old bugs... Paolo are you OK with using "Line #, Column #"? (I know
you already said you preferred the abbreviations, but Christian made good points)

Personally, I'm fine either way... actually I would be fine also with having
just the numbers: "14, 35".

Whatever is decided I don't think it's worth to let this bugreport live forever
from stringfreeze to stringfreeze: let's just take a decision whichever it is.

is this blocked by a freeze?  would adding the keyword help move it along?

Created attachment 34507 [details]
Here a case in which the English version is definitively short of space.

Here a case in which the English version is short of space.
Note that editing a file with > 9999 lines is definitively a common case.

I will add a comment for translators in the code:

/* Translators: "Ln" is an abbreviation for "Line", Col is an abbreviation for 

   "Column". Please, use abbreviations if possible to avoid space problems. */

I'm going to close this bug as WONTFIX.