n’t → n't

l10n
#1

Here is a request for a small adjustment in five English strings.

Almost all places in LibreOffice, straight apostrophes (', ASCII code 39
decimal) are used in "n't" endings like "don't" in the English strings. It
is used 209 places in version 4.4.

But there are five places where the character ’ (windows code page 1252
code 146 decimal) is used instead:
https://translations.documentfoundation.org/da/translate/#search=n’t&sfields=source&soptions=exact&unit=33503447

In the font used by the LibreOffice user interface in Windows, this looks a
bit odd.

It is in the following places (wether the single quotes go through this
mail system or are changed into the correct apostrophes, I don't know. But
the search above will show all five places in any case):

https://translations.documentfoundation.org/da/libo42_ui/translate/sw/uiconfig/swriter/ui.po#unit=64568098:
Don’t _split table over pages

https://translations.documentfoundation.org/da/libo43_ui/translate/sw/uiconfig/swriter/ui.po#unit=73203635:
Don’t _split table over pages

https://translations.documentfoundation.org/da/libo_ui/translate/sfx2/uiconfig/ui.po#unit=79248608:
Your changes will be lost if you don’t save them.

https://translations.documentfoundation.org/da/libo_ui/translate/sfx2/uiconfig/ui.po#unit=79248582:
_Don’t Save

https://translations.documentfoundation.org/da/libo_ui/translate/sw/uiconfig/swriter/ui.po#unit=33503447:
Don’t _split table over pages

Yes, this is a small thing, but nevertheless I think it should be changed
for the overall polished impression of LibreOffice.

Especially because one of the strings is very often shown to the user,
namely the "_Don’t Save".

Jesper

#2

Hi Jesper, *,

Typographically speaking, ’ *is* the correct character. The use of
so-called straight or typewriter apostrophes (and quotes) in computing is
basically restricting oneself to a limitation that is no longer justified
in Unicode-age. So in my view, the changing should ultimately go the other
way: ' → ’ (or ‘ where needed), and " → “”.

However, I agree that use of ’ vs. ' should be consistent in the UI. This
means that until there is no concensus on or at least majority support for
replacing all typewriter quotes with typographically correct symbols, the
old symbol should be used for the sake of consistency.

Best regards
Mihkel

#3

Is the function name AGGREGATE made accessible for translating?
I am not able to find the name neither on the Pootle server nor in the po files.
UI version 4.3 and 4.4.
The function is listed in English in the function wizard on my computer so it exists.
Perhaps a bug?

Kolbjoern

#4

2014-11-29 15:05 GMT-06:00 Mihkel Tõnnov said

Typographically speaking, ’ *is* the correct character. The use of
so-called straight or typewriter apostrophes (and quotes) in computing is
basically restricting oneself to a limitation that is no longer justified
in Unicode-age. So in my view, the changing should ultimately go the other
way: ' → ’ (or ‘ where needed), and " → “”.

+1.

I am actually planning to update the rest of strings in LibreOffice to
use the correct characters, but I guessed I had already annoyed the
other translators too much for this version, so that would be in 4.5.

In case you guys didn’t know, Apple [1], Microsoft [2] and GNOME [3]
are all recommending the use of typographical apostrophes and
quotation marks, among other characters that have been historically
replaced with ASCII imitations, such as the multiplication sign (×)
being incorrectly written with a Latin lowercase X, or three periods
(...) standing for the ellipsis (…).

Adolfo

#5

...

In case you guys didn’t know, Apple [1], Microsoft [2] and GNOME [3]
are all recommending the use of typographical apostrophes and
quotation marks, among other characters that have been historically

...

Said recommendations, while formaly correct, are subverted by the fact that there are no commonly accessible methods to keyboard-input all those "fancy" glyphs.

In OpenOffice (and in Word?) you may have add-ons, auto-correcting some of those cases. Otherwise than that you'd have to install smarty-pants (often, pain-in-the-..., too) keyboard input correctors or resort to mouse-clicking in the glyph tables.

I am actually planning to update the rest of strings in LibreOffice to
use the correct characters, but I guessed I had already annoyed the
other translators too much for this version, so that would be in 4.5.

So you will still annoy the translators, only more.

Program UI isn't a typography showcase. Why not leave the pragmatic simplification which serves it purpose? Does it break anything?

Yury

#6

2014-11-29 23:38 GMT-06:00 Yury Tarasievich said:

Said recommendations, while formaly correct, are subverted by the fact that
there are no commonly accessible methods to keyboard-input all those "fancy"
glyphs.

Wrong.

OS X and Linux distros include punctuation (which is not “fancy” at
all) out-of-the-box in most keyboard layouts—the user does not have to
do anything weird to get these working. The only OS missing the fun in
Windows, but bah.

Program UI isn't a typography showcase.

Of course it is! We’re building an office suite, remember? An office
suite which has to do with typography a great lot. And even if it
didn’t, it’s supposed to demostrate a level of polish and leave a
better, lasting impression on users. They do care about these things,
I certainly do as well. Even amateurish OS X applications implement
typographic quotation marks. Recent versions of GNOME core
applications also do. Windows Store apps are also in the boat. It was
only a matter of time.

#7

Fair enough, but please invent a process that makes these cosmetical
changes transparent for translators. People don't want to retranslate
or review 4000 strings just because you changed apostrophes in en-US.
Not to mention that many languages are unmaintaned in Pootle,

Thanks,
Andras

#8

2014.11.30 07:38, Yury Tarasievich rašė:

...

In case you guys didn’t know, Apple [1], Microsoft [2] and GNOME [3]
are all recommending the use of typographical apostrophes and
quotation marks, among other characters that have been historically

...

Said recommendations, while formaly correct, are subverted by the fact
that there are no commonly accessible methods to keyboard-input all
those "fancy" glyphs.

In OpenOffice (and in Word?) you may have add-ons, auto-correcting
some of those cases. Otherwise than that you'd have to install
smarty-pants (often, pain-in-the-..., too) keyboard input correctors
or resort to mouse-clicking in the glyph tables.

Just a reminder: in Pootle, it's possible to specify harder-to-input
characters for each language, which are then made available below the
text input field when localizing. While it's less convenient than
inputting them with the keyboard, it's still better than having a
separate character map application launched just to copy these few
characters. Furthermore, I think Pootle even shows such Unicode
characters in the source string as placeables, making them clickable.

And if you use Windows and want to make inputting these characters even
more convenient, you can always customize your keyboard layout adding
missing typographical symbols to the AltGr (or any other) layer. Here's
a free tool to do that:
http://msdn.microsoft.com/en-us/goglobal/bb964665.aspx.

I am actually planning to update the rest of strings in LibreOffice to
use the correct characters, but I guessed I had already annoyed the
other translators too much for this version, so that would be in 4.5.

So you will still annoy the translators, only more.

Program UI isn't a typography showcase. Why not leave the pragmatic
simplification which serves it purpose? Does it break anything?

I agree this will be annoying, because at the very least, the localizers
will have to re-approve a lot of their old translations when these
changes land. At least in the case of "don't" though, maybe this change
could be automated, if we ask Andras or Christian nicely? :slight_smile:

Regards,
Rimas

#9

2014.11.30 07:38, Yury Tarasievich rašė:

...

And if you use Windows and want to make inputting these characters even
more convenient, you can always customize your keyboard layout adding
missing typographical symbols to the AltGr (or any other) layer. Here's
a free tool to do that:
http://msdn.microsoft.com/en-us/goglobal/bb964665.aspx.

Well, as Adolfo tells us, it's "bah" to Windows users". However, Linux's en_US keymap (which I'm using right now) also does not have any of mentioned glyphs on the compose key.

I'm heavily using several fancy glyphs input add-ons in LO itself, and I tell you, it's not all fun.

Program UI isn't a typography showcase. Why not leave the pragmatic
simplification which serves it purpose? Does it break anything?

I agree this will be annoying, because at the very least, the localizers
will have to re-approve a lot of their old translations when these
changes land. At least in the case of "don't" though, maybe this change
could be automated, if we ask Andras or Christian nicely? :slight_smile:

I can guess with some confidence that having to redo apostrophes in, like, thousand strings by hand (and you can't automate, apostrophe's use in technology being what it is) just to have "correct" characters in the UI feels more like a slap in a face.

What's strictly "incorrect" in straight apostrophe, anyway?
Is any REAL purpose actually served by this change? Like, will anybody notice this or appreciate this or-so-nice touch in the computer screen material?
Will this conceal the fact that LibreO/ApacheOO itself isn't that great in typography in the documents it produces?

Yury

#10

For those purposes a fork of LibreOffice would be viable, named PureOffice.
But there would probably be no 100 % localizations provided for it.

Lp, m.

#11

...

What's strictly "incorrect" in straight
apostrophe, anyway?

...

Anyway, here's an idea for you guys about to suffer from this: diff the en_US source before and after apostrophe nice-fication, then create a program which looks at the apostrophe-change IDs only in source, and at the corresponding IDs in your translation, and does only the apo-nice-fication of the translation (straight confirmation, for that matter) if the diff boils down to apostrophes.

Shouldn't be too difficult, 10 years ago I was able to throw together AWK script doing approximately this for the Opera UI translation and maintain win/unix pair for a while with (almost) no pain.

Yury

#12

Please, guys, those of you who want to fight, could you please step outside
and do that, so the rest of us can work?

Just because you do not like an idea or are afraid of its consequences
there is no reason to shoot it down with sarcasm or other violent methods.
That is never helpful.

If you have fears, which I see you all have, and for very good reasons,
simply state the fears. Then we can talk about them in a rational manner
and try to find a good, balanced and viable solution. Don't let the fears
turn into aggression.

And if you can, supply exact numbers and sources to help show how big a
potential problem it is.

Best regards,
Jesper

#13

Hi, Jesper,

in LO Pootle 135 translation teams are stated. If we take out about 20
teams with really scarce tranlations, that means 115 teams.

5 changed strings in English UI x 115 = 575 changed strings in localization
po files to re-translate
115 people being affected by this change.

I am not aggressive and do not fight, just state my views, which is the
corner stone of democracy and open-source mantra, I guess. And it is my
deep conviction that sarcasm should not be banned, it is not illegal and it
sometimes does put problems into perspective in a very direct and fast way
- so it can be quite useful.

Lp, m.

#14

Hi, Jesper,

in LO Pootle 135 translation teams are stated. If we take out about 20
teams with really scarce tranlations, that means 115 teams.

5 changed strings in English UI x 115 = 575 changed strings in
localization po files to re-translate
115 people being affected by this change.

Very good with that type of facts. Thank you. I wonder how many changed or
new strings there were for instance from 4.3 to 4.4, for comparison?
Relative numbers are always better, to put things into perspective. My
guess, as I do not have the numbers and do not know how to find them, is
perhaps 500 changes? Given that guess, that would be 5 changes (well,
actually 12, as the 5 were only "don't") compared to 500 changes, or around
2 % of the total work.

But how come we would have to retranslate? Is there really no technical way
to make a change in the English string that is known to be purely a
correction to the English string with no effect on the translation? That
seems odd to me – but of course I accept that not everything is the way we
wish and that everything takes work to make. It just seems somewhat viable
to find a solution to avoid disturbing 115 people whenever a typo is found
in the English strings. It must have happened several times before.

I am not aggressive and do not fight,

Well, I disagree on that. You said: "a fork of LibreOffice would be viable,
named PureOffice". I might have misunderstood, but I took that as sarcasm,
and I see sarcasm (as opposed to irony) as aggression or hurtful emotional
violence, in an attempt to redicule the other party.

It is very possible to state one's opinions without resorting to that.

just state my views, which is the corner stone of democracy and
open-source mantra, I guess.

I absolutely agree! I have never said and never believed that one's views
should not be stated – on the contrary!

What I was talking about is the way they are stated. I believe they should
be stated simply as views, but without putting other people down because
they have differing views (as politicians so often do, which is why we are
all tired of them).

It is never necessary to put other people down because of their views. Just
state your own view without putting other views down. That is what I am
saying.

And it is my deep conviction that sarcasm should not be banned,

Well, we disagree on that. As I said, I see it as a form of emotional
violence (as opposed to irony), and I really don't like that. I believe it
is counter-productive and harmful. Maybe it shouldn't be directly banned,
but I do believe it should be very minimized when speaking in a large forum
like this. Just like other offensive ways of speaking are not welcome (like
"f... you, you little s...!" :-)).

it is not illegal

I never said it was illegal, and I know of no countries where it is.

and it sometimes does put problems into perspective in a very direct and
fast way - so it can be quite useful.

Oh definitely, yes, and the same can be said about other types of violence
(as I still believe it is): Definitely useful and powerful for the one
using it, but also definitely hurtful for the victim. And I do not find
personal usefulness with disregard to the victim to be a sufficient reason
to actually use it. I do believe in staying with rationality and respect. I
simply don't believe in violence, neither physical nor emotional (except
perhaps for extreme and very rare cases for immediate defence against
aggression).

But, as I said, I believe very much in stating one's opinions and that all
opinions are welcome. But respecting other's opinions without putting them
down is an integral part of that, and sarcasm and other forms of emotional
violence do have the effect of suppressing other people's views, as they
become afraid of stating their opinion if it can result in emotional
violence against them. That is exactly what is used by the leaders of
oppressive political systems: They use physical and emotional violence to
suppress people from expressing their views. For those leaders, it is very
efficient, as you said, but for democracy and openness I really cannot see
how it is helpful.

Or did you mean that sarcasm is good both for the one using it and for the
target? That the target will also find it is a good and constructive way of
communicating? Do you think the use of sarcasm increases or lowers the
aggression or amount of stress in the target?

Lp, m.

Best regards,
Jesper

#15

Hi Yury, *,

Well, as Adolfo tells us, it's "bah" to Windows users". However, Linux's
en_US keymap (which I'm using right now) also does not have any of mentioned
glyphs on the compose key.

Compose sequences should be the same regardless of keybloard layout,
you probably mean they're not accessible using group-switch key
(altGr) directly. (they are indeed not in the crippled plain en-US
layout, but are in the international layout)
But compose sequences are also available:
compose, apostroph, less/greater (or compose, less/greater, apostroph,
order usually doesn't matter with compose sequences)

i.e.
compose, ', > → ’
compose, ', < → ‘

same with the double quotation marks: compose, ", <less/greater>
compose, ", > → ”
compose, ", < → “

compose, >, > and compose << will give » and «

But with a keyboard-layout that actually makes use of the different
groups, you can also enter it with <altGr>[+<shift>]+<whateverkey>,
shift usually switching between the single or double variants ( ›‹ vs
»« and “” vs ‘’ for example)

I'm heavily using several fancy glyphs input add-ons in LO itself, and I
tell you, it's not all fun.

I agree this will be annoying, because at the very least, the localizers
will have to re-approve a lot of their old translations when these
changes land. At least in the case of "don't" though, maybe this change
could be automated, if we ask Andras or Christian nicely? :slight_smile:

Well, the only thing that can be done is to apply the old strings
despite the typographic changes, i.e. do a run that maps all
typographic quotes back to simple variants and then try to find an old
translation for that string and apply it.
In other words: Change the English string to typographic quotes, and
take the translations from the non-typographic variant.

So translators wouldn't need to retranslate, but also wouldn't see
what strings did change.

ciao
Christian

#16

Oh dear. What to do then, if one doesn't like the idea and does NOT in fact have "fears", only dislike for the extra work for close to none good reason?

I think sarcasm is valid here, likewise shooting down that which flies where it shouldn't.

Anyway, I have suggested the *technology* of dealing with the problem generally, for ALL translations here. I have been exploiting the principle for years, back then.

Yury

#17

30.11.2014. u 9:10, Andras Timar je napisao/la:

Program UI isn't a typography showcase.

Of course it is! We’re building an office suite, remember? An office
suite which has to do with typography a great lot. And even if it
didn’t, it’s supposed to demostrate a level of polish and leave a
better, lasting impression on users. They do care about these things,
I certainly do as well. Even amateurish OS X applications implement
typographic quotation marks. Recent versions of GNOME core
applications also do. Windows Store apps are also in the boat. It was
only a matter of time.

Fair enough, but please invent a process that makes these cosmetical
changes transparent for translators. People don't want to retranslate
or review 4000 strings just because you changed apostrophes in en-US.
Not to mention that many languages are unmaintaned in Pootle,

Thanks,
Andras

I agree with Andras, Yury and other, we don't need yet another cosmetic change which serves no purpose and only requires hours and hours of work to get BACK to where we are now.

First we had those UI popup changes which changed access keys from ~ to _. Some strings also changed but most didn't have any change except that. That dragged on for 2 or 3 major releases.

Then in 4.4 we got some more cosmetic changes which add : on end of strings. Hundred of strings stayed same except for that, but hey, hours and hours of work again.

In 4.4 I also noticed quite few strings which only change was first capital letter on some or all words in string. I'm wondering if english has ANY rules regarding spelling or you can just put capital letter anywhere you want. Anyway, that was cosmetic change also, since all of my strings stayed same.

And now we have biggest challenge of all in front of us, let's change thousands of string in a way noone will notice, just those lazy people who have nothing else to do except retranslate same old string and try to write it same as it was. That's hardly possible since we don't have TM for new strings, only old.

Anyway, as Andras said, do what you want, but please fix all translations your self or do it in a way it doesn't affect hundreds of people.

Mihovil

#18

Hi,

2014.11.30 16:23, Christian Lohmaier wrote:

I agree this will be annoying, because at the very least, the localizers
will have to re-approve a lot of their old translations when these
changes land. At least in the case of "don't" though, maybe this change
could be automated, if we ask Andras or Christian nicely? :slight_smile:

Well, the only thing that can be done is to apply the old strings
despite the typographic changes, i.e. do a run that maps all
typographic quotes back to simple variants and then try to find an old
translation for that string and apply it.
In other words: Change the English string to typographic quotes, and
take the translations from the non-typographic variant.

So translators wouldn't need to retranslate, but also wouldn't see
what strings did change.

If this can be done, I'm sure it would make most localizers happier.
Especially in cases like "don't", where the translation most likely
doesn't even contain the glyph that has changed. As for quotes, these
most likely exist in localized content as well, but I'd say it has been
localizer's responsibility to use typographically correct ones from the
very beginning. And for those of us don't care about "typographical
nonsense", forcing them to resubmit hundreds of strings will hardly
change that stance.

Changes to ellipsis characters should probably be applied automatically
as well, except for a few locales (like Japanese), for which Unicode
ellipsis is displayed as three vertically aligned dots, which at least a
couple years back seems to have been very unexpected in application UIs.

Regards,
Rimas

#19

Lets invent a new language in the world named Liboish - LibreOffice
language - that in fact is often confused with en_US, but it is not the
same.

I suggest to create a new entry in Pootle, named en-US so that we get a
translation from Liboish to English. Other languages translates directly
from Liboish and we are all happy not to redo our work.

(Apologizes for the inapropriate sense of humour, but I saw this extra
work comming months ago. 99% of my 4.4 UI was rework)

#20

But how come we would have to retranslate?

It shows up as "untranslated", and the only way to change the status is
to retranslate it, even if that retranslation is nothing more than a
mouse click approving the existing translation.

to find a solution to avoid disturbing 115 people whenever a typo is found
in the English strings.

The solution is for each variant of each language to be in Pootle as a
target language. Corrections are made in the target_language_space, for
each affected language, dialect, or cant.

Rephrasing all that.

Source_LibreOffice_language = Whatever the developers put in the strings
to be translated. The language in those strings is irrelevant.

Source_LibreOffice_language -> EN_ca
Source_LibreOffice_language -> EN_nz
Source_LibreOffice_language -> EN_uk
Source_LibreOffice_language -> EN_us
Source_LibreOffice_language -> En_za
Source_LibreOffice_language -> DE_ar
Source_LibreOffice_language -> DE_ch
Source_LibreOffice_language -> DE_de
Source_LibreOffice_language -> DE_na
Source_LibreOffice_language -> DE_us
etc

Vocabulary found in Source_LibreOffice_language consists only of
whatever the developers use/used. It is not, and need not correlate with
any known language, whether natural, constructed, or artificial.

It must have happened several times before.

It has. Every time it happens, a group of translators complains.

Oliver's statement « People don't want to retranslate
or review 4000 strings just because you changed apostrophes in en-US.»
should not have been necessary, because fixing typographical conventions
in one dialect of one language should _never_ require changes in another
dialect, let alone another language.

jonathon

  * English - detected
  * English

  * English

<javascript:void(0);>