A proposal for separate English localization

classic Classic list List threaded Threaded
19 messages Options
Kaganski Mike Kaganski Mike
Reply | Threaded
Open this post in threaded view
|

A proposal for separate English localization

Hello!

Recently I was approached by members of our local community who manage
the translation of LibreOffice UI to Russian. I was told that they have
a regularly recurring problem, that each time a developer changes an
English string in LibreOffice UI, they have that string untranslated in
pootle, and need to repeat same actions again to re-translate it. What's
worse, the translation that pootle suggest in that case is oftentimes wrong.

This is *not* related to changes that were recently made by Caolan to
the localization machinery; rather, it's more like commit
https://cgit.freedesktop.org/libreoffice/core/commit/?id=029f2fdc where
hundreds of strings were slightly changed for consistency in UI. That's
of course necessary to do, but the specifics of our translation makes
the English (built in) translation the source for all others, and every
change in it (even irrelevant for a other translation that, say, has the
strings capitalized consistently) forces *all translation teams* to do
the extra work.

I received a proposal that looks like that: make an English translation
yet another ordinary translation, and make strings in code immutable.
When a developer decides to change English strings, those changes would
go to the translation, not to the source. This way, the new strings
would, as before, add work to translation teams, but changes to English
translation that are irrelevant to other translations will be local.

I had a discussion on the topic with erAck, and he raised several
concerns. First, the English translation is the fallback in case there's
no localized translated string. Second: developers would not work with
pootle, and that would raise need for English localization team. Third,
that developers don't know if thier change to English UI is or is not
relevant to other translation; English being the source for others, the
change might need to be reflected in the other translations, so each
change should be reviewed by localizers anyway.

When I discussed the topic with Olivier, he also told me that the
workflow is very uncomfortable for translation teams, and stressed that
the tooling gives wrong proposals for changed translations, thus not
helping in the process.

I wanted to ask all interested parties to discuss the topic, and share
your opinions. From my side, I suppose that the concerns raisedby Eike
could be sloved like this:

1. The English translation becomes the fallback. In case that there's no
English string for an element, that should be blocked on compilation
stage, or alternatively the immutable code string would become the fallback.

2. The English translation should be created in a different way (in a
dedicated source file?) to be easy for developers to change.

3. Any change in English translation (not in immutable source strings!)
would trigger all other translations of this string to become fuzzy
(thus not loosing previous translation, but just signaling the
requirement to review).

Hope this makes sense. I must admit that I myself don't have a deep
knowledge in our localization machinery, so if this isn't reasonable,
please ignore my proposals.

--
Best regards,
Mike Kaganski

_______________________________________________
LibreOffice mailing list
[hidden email]
https://lists.freedesktop.org/mailman/listinfo/libreoffice
Fitoschido Fitoschido
Reply | Threaded
Open this post in threaded view
|

Re: A proposal for separate English localization

Why is it only obvious to me that creating a separate “English locale” (IOW, a complete copy of the source strings which would have to be kept in sync and coherent at all times) is not sustainable?

Fix Pootle. Or let’s have Weblate.

_______________________________________________
LibreOffice mailing list
[hidden email]
https://lists.freedesktop.org/mailman/listinfo/libreoffice
Kaganski Mike Kaganski Mike
Reply | Threaded
Open this post in threaded view
|

Re: A proposal for separate English localization

On 10/15/2017 1:44 PM, Adolfo Jayme Barrientos wrote:
> Why is it only obvious to me that creating a separate “English locale”
> (IOW, a complete copy of the source strings which would have to be kept
> in sync and coherent at all times) is not sustainable?

Why kept coherent all times? Initially the strings both in source, and
in locale, would be the same. But imagine a pair like this:

     source             locale
"do foo action"    "do foo action"

The source string is the key for all translations, and is kept immutable
after creation. But the localization string might change later, e.g. to
be consistent, like this:

     source             locale
"do foo action"    "Do Foo action"

so they go out of sync.

Why not sustainable? Actually, we somehow expect all of our translations
to be kept in sync (as well as possible); so why do we think about this
one differently? Actually we have multiple places in code that should be
kept synchronized at all times, and this works well (e.g., some
enumeration values); and if the sync state is being checked at compile
time (like some plugin maybe), this is absolutely possible.

--
Best regards,
Mike Kaganski
_______________________________________________
LibreOffice mailing list
[hidden email]
https://lists.freedesktop.org/mailman/listinfo/libreoffice
David Tardon David Tardon
Reply | Threaded
Open this post in threaded view
|

Re: A proposal for separate English localization

In reply to this post by Kaganski Mike
Hi,

On Fri, Oct 13, 2017 at 09:31:41PM +0000, Kaganski Mike wrote:
> 3. Any change in English translation (not in immutable source strings!)
> would trigger all other translations of this string to become fuzzy
> (thus not loosing previous translation, but just signaling the
> requirement to review).

Wouldn't it be better to aim just for this and skip the hassle of adding
a separate English translation?

D.
_______________________________________________
LibreOffice mailing list
[hidden email]
https://lists.freedesktop.org/mailman/listinfo/libreoffice
Kaganski Mike Kaganski Mike
Reply | Threaded
Open this post in threaded view
|

Re: A proposal for separate English localization

On 10/16/2017 10:08 AM, David Tardon wrote:
> On Fri, Oct 13, 2017 at 09:31:41PM +0000, Kaganski Mike wrote:
>> 3. Any change in English translation (not in immutable source strings!)
>> would trigger all other translations of this string to become fuzzy
>> (thus not loosing previous translation, but just signaling the
>> requirement to review).
>
> Wouldn't it be better to aim just for this and skip the hassle of adding
> a separate English translation?

Well, I'm not sure how that solution would help to tell apart the two
different situations:
1. When a string is being corrected
2. When a string goes, but another string comes.

First is simply a correction of existing string, that means that the
translations should only review if their old translations are still OK.
Second is when one feature was, e.g., removed from a dialog, but
entirely different feature is added there. This is something that should
be definitely translated by teams independently of some text that could
exist there before.

--
Best regards,
Mike Kaganski
_______________________________________________
LibreOffice mailing list
[hidden email]
https://lists.freedesktop.org/mailman/listinfo/libreoffice
sophi sophi
Reply | Threaded
Open this post in threaded view
|

Re: A proposal for separate English localization

In reply to this post by Kaganski Mike
Hi Mike,

Le 13/10/2017 à 23:31, Kaganski Mike a écrit :
> Hello!
>
> Recently I was approached by members of our local community who manage
> the translation of LibreOffice UI to Russian. I was told that they have
> a regularly recurring problem, that each time a developer changes an
> English string in LibreOffice UI, they have that string untranslated in
> pootle, and need to repeat same actions again to re-translate it. What's
> worse, the translation that pootle suggest in that case is oftentimes wrong.

Please read the l10n list archives, this has already been discussed
numerous times and the reason why it's not possible are clearly
explained here. Same for the problems when typos are fixed in the
source, and the current problem of scripting the changes. See my last
mail with topic 'Please read'. Thanks
Cheers
Sophie

--
Sophie Gautier [hidden email]
GSM: +33683901545
IRC: sophi
Release coordinator
The Document Foundation
_______________________________________________
LibreOffice mailing list
[hidden email]
https://lists.freedesktop.org/mailman/listinfo/libreoffice
Kaganski Mike Kaganski Mike
Reply | Threaded
Open this post in threaded view
|

Re: A proposal for separate English localization

On 10/16/2017 3:16 PM, Sophie wrote:

> Hi Mike,
>
> Le 13/10/2017 à 23:31, Kaganski Mike a écrit :
>> Hello!
>>
>> Recently I was approached by members of our local community who manage
>> the translation of LibreOffice UI to Russian. I was told that they have
>> a regularly recurring problem, that each time a developer changes an
>> English string in LibreOffice UI, they have that string untranslated in
>> pootle, and need to repeat same actions again to re-translate it. What's
>> worse, the translation that pootle suggest in that case is oftentimes wrong.
>
> Please read the l10n list archives, this has already been discussed
> numerous times and the reason why it's not possible are clearly
> explained here. Same for the problems when typos are fixed in the
> source, and the current problem of scripting the changes. See my last
> mail with topic 'Please read'. Thanks
> Cheers
> Sophie
>

Sorry Sophie, I cannot see how that mail is relevant here (I stressed
that it's not related to the gettext work), and how it explains the
impossibility of solution direction suggested. Would be most thankful if
you post a direct link to the mail you refer to (I looked at
https://listarchives.libreoffice.org/global/l10n/msg11231.html).

--
Best regards,
Mike Kaganski
_______________________________________________
LibreOffice mailing list
[hidden email]
https://lists.freedesktop.org/mailman/listinfo/libreoffice
jani libreoffice jani libreoffice
Reply | Threaded
Open this post in threaded view
|

Re: A proposal for separate English localization

In reply to this post by Kaganski Mike
Hi

Actually many international projects, do not use english strings in the source as such, they use identifiers. All project I know of, have let the developer enter a suggested string, which is then through tooling converted to an identifier, and the suggestion is moved to pootle.

Please remember not all developers are native english speaking, therefore the suggestions often need some extra work, to great irritation for many translators.

I have never understood why we make english a special case, and assume all developers are perfect english speakers.

just my 2ct.
rgds
jan I.
_______________________________________________
LibreOffice mailing list
[hidden email]
https://lists.freedesktop.org/mailman/listinfo/libreoffice
Eike Rathke-2 Eike Rathke-2
Reply | Threaded
Open this post in threaded view
|

Re: A proposal for separate English localization

In reply to this post by Kaganski Mike
Hi Mike,

On Sunday, 2017-10-15 10:55:17 +0000, Kaganski Mike wrote:

> The source string is the key for all translations, and is kept immutable
> after creation. But the localization string might change later, e.g. to
> be consistent, like this:
>
>      source             locale
> "do foo action"    "Do Foo action"
>
> so they go out of sync.

And that is bad. If what is visible in the English UI does not match the
source then finding the source string of some UI element gets
complicated. Being able to locate the source of an UI string and from
there dive into its use in the code is a helpful procedure.

> Why not sustainable? Actually, we somehow expect all of our translations
> to be kept in sync (as well as possible); so why do we think about this
> one differently? Actually we have multiple places in code that should be
> kept synchronized at all times, and this works well (e.g., some
> enumeration values);

Translations (pootle etc.) are not code. In fact the primary source of
translations isn't even in a code repository, just merged from time to
time to the translations/ submodule. Technically it also doesn't matter
how much is translated to one language or if translations are accurate
(with a few exceptions).

> and if the sync state is being checked at compile
> time (like some plugin maybe), this is absolutely possible.

Maybe I got you wrong. Are you talking about some merge back from
translations into source code to have the source synced with the English
translation?

  Eike

--
LibreOffice Calc developer. Number formatter stricken i18n transpositionizer.
GPG key 0x6A6CD5B765632D3A - 2265 D7F3 A7B0 95CC 3918  630B 6A6C D5B7 6563 2D3A
Care about Free Software, support the FSFE https://fsfe.org/support/?erack

_______________________________________________
LibreOffice mailing list
[hidden email]
https://lists.freedesktop.org/mailman/listinfo/libreoffice

signature.asc (849 bytes) Download Attachment
Eike Rathke-2 Eike Rathke-2
Reply | Threaded
Open this post in threaded view
|

Re: A proposal for separate English localization

In reply to this post by Kaganski Mike
Hi Mike,

On Monday, 2017-10-16 12:16:01 +0000, Kaganski Mike wrote:

> On 10/16/2017 10:08 AM, David Tardon wrote:
> > On Fri, Oct 13, 2017 at 09:31:41PM +0000, Kaganski Mike wrote:
> >> 3. Any change in English translation (not in immutable source strings!)
> >> would trigger all other translations of this string to become fuzzy
> >> (thus not loosing previous translation, but just signaling the
> >> requirement to review).
> >
> > Wouldn't it be better to aim just for this and skip the hassle of adding
> > a separate English translation?
>
> Well, I'm not sure how that solution would help to tell apart the two
> different situations:
> 1. When a string is being corrected
> 2. When a string goes, but another string comes.
>
> First is simply a correction of existing string, that means that the
> translations should only review if their old translations are still OK.
> Second is when one feature was, e.g., removed from a dialog, but
> entirely different feature is added there. This is something that should
> be definitely translated by teams independently of some text that could
> exist there before.
For a new string replacing an old one and introducing a different
functionality a new context string should be used as well. I don't see
a problem with this.

  Eike

--
LibreOffice Calc developer. Number formatter stricken i18n transpositionizer.
GPG key 0x6A6CD5B765632D3A - 2265 D7F3 A7B0 95CC 3918  630B 6A6C D5B7 6563 2D3A
Care about Free Software, support the FSFE https://fsfe.org/support/?erack

_______________________________________________
LibreOffice mailing list
[hidden email]
https://lists.freedesktop.org/mailman/listinfo/libreoffice

signature.asc (849 bytes) Download Attachment
Kaganski Mike Kaganski Mike
Reply | Threaded
Open this post in threaded view
|

Re: A proposal for separate English localization

In reply to this post by Eike Rathke-2
Hi,

On 10/17/2017 2:39 PM, Eike Rathke wrote:

> Hi Mike,
>
> On Sunday, 2017-10-15 10:55:17 +0000, Kaganski Mike wrote:
>
>> The source string is the key for all translations, and is kept immutable
>> after creation. But the localization string might change later, e.g. to
>> be consistent, like this:
>>
>>       source             locale
>> "do foo action"    "Do Foo action"
>>
>> so they go out of sync.
>
> And that is bad. If what is visible in the English UI does not match the
> source then finding the source string of some UI element gets
> complicated. Being able to locate the source of an UI string and from
> there dive into its use in the code is a helpful procedure.
>
>> Why not sustainable? Actually, we somehow expect all of our translations
>> to be kept in sync (as well as possible); so why do we think about this
>> one differently? Actually we have multiple places in code that should be
>> kept synchronized at all times, and this works well (e.g., some
>> enumeration values);
>
> Translations (pootle etc.) are not code. In fact the primary source of
> translations isn't even in a code repository, just merged from time to
> time to the translations/ submodule. Technically it also doesn't matter
> how much is translated to one language or if translations are accurate
> (with a few exceptions).
>
>> and if the sync state is being checked at compile
>> time (like some plugin maybe), this is absolutely possible.
>
> Maybe I got you wrong. Are you talking about some merge back from
> translations into source code to have the source synced with the English
> translation?

This should be considered in context of #2 of the original message
(https://lists.freedesktop.org/archives/libreoffice/2017-October/078629.html),
which is "The English translation should be created in a different way
(in a dedicated source file?) to be easy for developers to change."

With that in sight, I assume something like this:

1. Source files that contain references to translatable strings (in the
form like "do foo action" above). Already present.
2. Per-module (?) "localization.en_US.txt", with pairs like
     "do foo action" = Do Foo action
   - this already makes it possible to locate the code from UI string
with single indirection
3. A script that is run by make that checks that each string from #1 has
its counterpart in #2, and errors out on failure; otherwise, compiles
the en-US localization.

The other translations continue to be served as they are now. But in
case an English string changes in a localization.en_US.txt, then all
other translations flag their relevant string as needed to be reviewed
(but not loose their current translations!). That could be possible,
because underlining code string (identifier "do foo action") stays
unchanged. That needs a script, that would to that trick (checking if
English translation of a string is changed) when other translations'
pootles are updated.

This could be further extended to allow including context into the
reference string in code, to look like
   gettext("moduleX/dialogY/do foo action")
(but I don't know if that's helpful, and this isn't a subject of my
proposal).

On 10/17/2017 2:46 PM, Eike Rathke wrote:
 > For a new string replacing an old one and introducing a different
 > functionality a new context string should be used as well. I don't see
 > a problem with this.

If you have many strings that you not only have to check, but also old
translation is lost, (and it's not always easy for translator to get
access to a part of UI with that string to get clear idea about it) the
problem is evident. AFAICT, those who complain encounter that problem on
a regular basis. Being able to just flag strings, but not loose current
translation, is the main idea.

--
Best regards,
Mike Kaganski
_______________________________________________
LibreOffice mailing list
[hidden email]
https://lists.freedesktop.org/mailman/listinfo/libreoffice
jonathon-6 jonathon-6
Reply | Threaded
Open this post in threaded view
|

Re: A proposal for separate English localization

In reply to this post by jani libreoffice
On 10/17/2017 09:17 AM, Jan Iversen wrote:

> I have never understood why we make English a special case, and assume all developers are perfect English speakers.

Two reasons:
* Inertia;
* An unwillingness to create both English(US) and English(UK) as
independent l10n projects.

That every professionally run l10n project does «let the developer enter
a suggested string, which is then through tooling converted to an
identifier, and the suggestion is moved to pootle.» appears to be
irrelevant.

That every time something in the English(US) strings get changed, means
each L10N team has to spend hours figuring out what, if anything --- and
as oft as not it is nothing -- was changed, is more than ridiculous.
(IIRC, if the translators were paid at the usual and normal translation
rates, each time the English (US) strings changed, the cost would be
US$1,500,000.)

jonathon
_______________________________________________
LibreOffice mailing list
[hidden email]
https://lists.freedesktop.org/mailman/listinfo/libreoffice
sophi sophi
Reply | Threaded
Open this post in threaded view
|

Re: A proposal for separate English localization

In reply to this post by Kaganski Mike
Le 16/10/2017 à 14:22, Kaganski Mike a écrit :

> On 10/16/2017 3:16 PM, Sophie wrote:
>> Hi Mike,
>>
>> Le 13/10/2017 à 23:31, Kaganski Mike a écrit :
>>> Hello!
>>>
>>> Recently I was approached by members of our local community who manage
>>> the translation of LibreOffice UI to Russian. I was told that they have
>>> a regularly recurring problem, that each time a developer changes an
>>> English string in LibreOffice UI, they have that string untranslated in
>>> pootle, and need to repeat same actions again to re-translate it. What's
>>> worse, the translation that pootle suggest in that case is oftentimes wrong.
>>
>> Please read the l10n list archives, this has already been discussed
>> numerous times and the reason why it's not possible are clearly
>> explained here. Same for the problems when typos are fixed in the
>> source, and the current problem of scripting the changes. See my last
>> mail with topic 'Please read'. Thanks
>> Cheers
>> Sophie
>>
>
> Sorry Sophie, I cannot see how that mail is relevant here (I stressed
> that it's not related to the gettext work), and how it explains the
> impossibility of solution direction suggested. Would be most thankful if
> you post a direct link to the mail you refer to (I looked at
> https://listarchives.libreoffice.org/global/l10n/msg11231.html).

This is not the oldest, there were previous discussions already:
http://nabble.documentfoundation.org/Workflow-between-dev-UX-and-l10n-teams-td4136598.html


Cheers
Sophie


--
Sophie Gautier [hidden email]
GSM: +33683901545
IRC: sophi
Release coordinator
The Document Foundation
_______________________________________________
LibreOffice mailing list
[hidden email]
https://lists.freedesktop.org/mailman/listinfo/libreoffice
jonathon-6 jonathon-6
Reply | Threaded
Open this post in threaded view
|

Re: A proposal for separate English localization

In reply to this post by Fitoschido
On 10/15/2017 10:44 AM, Adolfo Jayme Barrientos wrote:
> Why is it only obvious to me that creating a separate “English locale”
> (IOW, a complete copy of the source strings which would have to be kept in
> sync and coherent at all times) is not sustainable?

The _ONLY_ issue with having both English(US) and English(UK), is the
lack of an initial l10n team for those two languages.

That every professionally run localisation/translation project allows
_voluntary_ language dependencies, but prohibits _involuntary_ language
dependencies, simply reinforces just how sustainable the model is.

Even for the few voluntary language dependent l10n teams, the reliance
on an involuntary language dependency can be frustrating.  (What do you
mean that none of those 10,000 changed strings aren't changed strings?)

jonathon
_______________________________________________
LibreOffice mailing list
[hidden email]
https://lists.freedesktop.org/mailman/listinfo/libreoffice
Wols Lists Wols Lists
Reply | Threaded
Open this post in threaded view
|

Re: A proposal for separate English localization

On 17/10/17 15:51, Toki wrote:
> On 10/15/2017 10:44 AM, Adolfo Jayme Barrientos wrote:
>> > Why is it only obvious to me that creating a separate “English locale”
>> > (IOW, a complete copy of the source strings which would have to be kept in
>> > sync and coherent at all times) is not sustainable?

Given that "English" itself is not coherent, you cannot have an
"English" locale that is "in sync and coherent". It's an impossibility.

> The _ONLY_ issue with having both English(US) and English(UK), is the
> lack of an initial l10n team for those two languages.

While I can't see it impacting LO, you also need to remember that en_UK
and en_US are actually two distinct languages with different
vocabularies and spellings (and indeed, maybe grammars?).

Okay, 99% of it is the same, but can somebody please tell me what a
rubber is? (If you look at my email address you'll know what *I* think
it is, but to an American it will mean something *completely* different
:-) There are plenty of words and phrases like that, and for a really
good example just take the phrase "to table a suggestion". Which has
OPPOSITE meanings in English and American.

I hate seeing the word "color" everywhere - my spell checker objects to
it as indeed it should - but that is the standard spelling when
programming :-( And using that spelling in Writer's menus, when the
spell-checker correctly objects to it, is not right.

Etc etc.

Cheers,
Wol
_______________________________________________
LibreOffice mailing list
[hidden email]
https://lists.freedesktop.org/mailman/listinfo/libreoffice
jonathon-6 jonathon-6
Reply | Threaded
Open this post in threaded view
|

Re: A proposal for separate English localization

On 10/20/2017 03:54 PM, Wols Lists wrote:

> and en_US are actually two distinct languages with different vocabularies and spellings (and indeed, maybe grammars?).

FWIW, _African-American Vernacular English_ utilizes a tense that is not
present in either _Standard American English_ nor _Received English_.

> Okay, 99% of it is the same, but can somebody please tell me what a rubber is?

Go shag somewhere else. This isn't a crib. <g>

###

If users of African American Vernacular English want to create that
L10N, more power to them.  Likewise, if users of Scottish English want
to create an L10N, let Bobby lede the way.

jonathon
_______________________________________________
LibreOffice mailing list
[hidden email]
https://lists.freedesktop.org/mailman/listinfo/libreoffice
Wols Lists Wols Lists
Reply | Threaded
Open this post in threaded view
|

Re: A proposal for separate English localization

On 20/10/17 19:25, jonathon wrote:
> If users of African American Vernacular English want to create that
> L10N, more power to them.  Likewise, if users of Scottish English want
> to create an L10N, let Bobby lede the way.

I think you mean users of the Scots language. Not to be confused with
the language of the Scots.

Sassenachs - ie Angles - speak Scots. Scots speak Gaelic. (And it's the
Saxons who speak English :-)

:-)

Cheers,
Wol
_______________________________________________
LibreOffice mailing list
[hidden email]
https://lists.freedesktop.org/mailman/listinfo/libreoffice
jonathon-6 jonathon-6
Reply | Threaded
Open this post in threaded view
|

Re: A proposal for separate English localization

On 10/21/2017 09:16 PM, Wols Lists wrote:

> I think you mean users of the Scots language. Not to be confused with the language of the Scots.

There is a dialect of English called Scottish English.  It is a
combination of Gaelic and English.

> Sassenachs - ie Angles - speak Scots. Scots speak Gaelic. (And it's the
> Saxons who speak English :-)

And the Celts speak?



jonathon




_______________________________________________
LibreOffice mailing list
[hidden email]
https://lists.freedesktop.org/mailman/listinfo/libreoffice
Wols Lists Wols Lists
Reply | Threaded
Open this post in threaded view
|

Re: A proposal for separate English localization

On 21/10/17 23:44, jonathon wrote:
> On 10/21/2017 09:16 PM, Wols Lists wrote:
>
>> I think you mean users of the Scots language. Not to be confused with the language of the Scots.
>
> There is a dialect of English called Scottish English.  It is a
> combination of Gaelic and English.

And what relation is that to the language Scots? Which is what the
people from lowland Scotland speak (and they're not Scots, despite being
Scottish :-)

To confuse matters even further, we all know Nova Scotia (or "New
Scotland"). But where is Scotia? :-)
>
>> Sassenachs - ie Angles - speak Scots. Scots speak Gaelic. (And it's the
>> Saxons who speak English :-)
>
> And the Celts speak?
>
Welsh - which I believe was the name given by the Anglo-Saxons to the
inhabitants of Britain before they arrived.

It then got repurposed by Normans - or maybe Wales was not part of
England at the time of the Conquest.

I'm more interested in the Scottish side of things, but what is
noticeable is that in the 10th and 11th centuries Britain was coalescing
into a single nation, and William rather mucked things up. Edward the
Confessor *allegedly* made him his heir (not something Edward had the
power to do), and William and his successors took this as a claim to all
of Britain despite Edward only being King of the South East (okay, most
of it :-).

If it wasn't for William, the remaining kingdoms might well have merged,
rather than been forcibly joined by conquest. The English kings were
elected, which is sort of how the last great merger before the Conquest
took place.

Cheers,
Wol
_______________________________________________
LibreOffice mailing list
[hidden email]
https://lists.freedesktop.org/mailman/listinfo/libreoffice