Date: prev next · Thread: first prev next last
2019 Archives by date, by thread · List index

Dear Seda,

We are sorry if our explanation seems messy to you.

We have been in contact with (back-then) head of Language Committee, and also have seen (obviously overstated in our subjective opinion) claims by Min.Diaspora that they are working on unified orthography.

While our subjective opinion is that they are exaggerated, we have no authority to claim that it's a false statement, and cannot officially ignore that or state otherwise.

The questionable work on unified orthography is, however, tangential to this discussion and has only secondary role for decision to use hye(soviet) for hy_RU. If you are really interested in actual situation, please read on, and also feel free to contact us at +374 55 409 809 for a more thorough explanations.

Following is our mission:

We are building a GNU/Linux based OS with full support of all Armenian literary (Գրական) language versions except middle-Armenian.

1) Grabar - ISO 639-3 code "xcl",
2) Western Armenian (ISO 639-3 code "hyw")
3) and Eastern Armenian (639-3 code "hye")

And including both orthographies for Armenian Eastern variant:
3*) Eastern classic
3**) Eastern modern

Note that unfortunately ISO 639-3 does not distinguish between the 2, therefore we have decided to use ISO 3166 codes for differentiation, namely: a) RU - definitely meaning hye(modern), because Armenian diaspora in RF is mainly educated with hye-modern b) IR - definitely meaning hye(classic), because Armenian diaspora of Iran is mainly educated with hye-classic c) AM - here we are in dilemma. Official laws of Armenia do not isolate any of the 1,2,3,3*,3** as official language of the republic. We have double-checked this with the State Lanugate Committee of RA in writing and have written response.

Here a little more technical details are due to understand why it is a problem and what solution has been chosen for it:

As you probably know for LOCALE setting one typically specifies 2 codes - a language code (typically ISO-639) and a country code (typically ISO 3166).

So in our GNU/Linux based Operating System, one who resides in RF would definitely have RU in their LOCALE, and one in Iran wout definitely have IR. And since we care about the diasporas, we do want to support them, and this is tangential to the problem mentioned in (c) above.

But for somebody who lives in Armenia, we can unambiguously set proper locales only for hyw_AM and xcl_AM, while for hye_AM (and one could argue that also for hy_AM) we have lack of clarity in legislation. De-facto the population of Armenia would probably vote for hye_AM meaning armenian-eastern with modern orthography. While a small team of researchers, including us, would prefer it to mean armenian-eastern with classic orthogrpahy. Finally, as mentioned in statement that you have referred to, the head of Language Committee told to us that currently they are urged by Min-Diaspora to not give any definitive answer to that, but only promise to give it after coming to consensus about "unified armenian orthography".

Bottom line, our locale numeration goes as following:
1) xcl_RU, xcl_IR, xcl_AM - Classic Armenian
2) hyw_RU, hyw_IR, hyw_AM - Western Armenian
3) hye_IR - Eastern Armenian with Classic Orthogrpahy
4) hye_RU - Eastern Armenian with Modern (aka soviet) Orthography
5) hye_AM - our personal choice for the GNU/Linux OS we are building - Eastern Armenian with Classic Orthography 6) hy_AM - our choice is hye_AM, although one could go as far as arguing that this should be xcl_AM (e.g. Alexander Qananyan - who is advising us in this activity)

Hope this makes it clear and we will be glad to cooperate with you on any of the above mentioned topics, as well as continue this specific discussion related with LibreOffice. I hope it is clear from above that we need to have differentiation in nomenclature, to distinguish the Armenian Eastern Modern and Armenian Eastern Classic. If you have strong preference for Armenian Eastern Modern (your translations) to be named somehow - we can respect those preferences, unless they contradict the industrial standards of naming the locales. We believe that OpenOffice team does respect GNU/Linux (and generally POSIX) approach of using ISO codes for locale names, and more specifically - language code + country code combination.

For that purpose, let's narrow down our discussion to following:

Our team needs to put in translations of Armenain Eastern Classic, Armenian Eastern Modern/Soviet, and Armenian Classic. The other variants will come later in our roadmap. For these 3 we are using the following codes:

1) Armenian Classic: xcl (any country code)
2) Armenian Eastern Classic: hye_IR, hy_IR, and unless you have strong objections, also hy_AM and hye_AM 3) Amrenian Eastern Modern: hye_RU, hy_RU (we believe that your main argument is that this should also be denoted by hy_AM and hye_AM?)

Please note that due to orthographic ambiguity between 2/3 the "hy" and "hye" alone cannot denote a locale (PO file) unambiguously, so country code needs to be specified.

If you agree with this clarification of the subject of our discussion, then, please, let's complete it asap and come up with solution that is not only respecting our own desires, but legislation of Armenia and also future generation rights. Specifically - we cannot claim that there is a legal justification for hy_AM/hye_AM = hy_RU/hye_RU (i.e. denote modern orthography), nor there is a legal justification for it to denote classic orthography (hy_IR/hye_IR). More precisely/pedantically, ase mentioned in (6) above, there is no even legal justification to assume that hy = hye. So we have following open questions:

1) hy = hye or rather leave it ambiguous and let each Operating System Vendor make their own choice, and even let User decide?
2) hye_AM = classic or modern variant of Eastern orthography ?

Our preferred answers are:
1) hy = xcl
2) hye_AM = classic orthography of Eastern Armenian

But we realize that our customers will force us to use:
1) hy = hye
2) hy_AM = soviet orthography
3) they would not care about hye_AM or anything else.

We strongly believe that "politically correct" way of solving the situation is: 1) ask our customers to set OS LOCALE to hy_RU if they want to use Eastern Armenian with modern orthography 2) ask our customers to set OS LOCALE to hy_IR if they want to use Eastern Armenian with classic orthogrpahy 3) temporarily use hy/hye_AM for Eastern Armenian Classic until our MinEdu/Language Committee will come up with a clarification

From your argumentation, it seems that you would prefer to use Eastern Armenian Modern for (3). Can we say that this is the main argument we have to discuss now, or is there any other point that needs to be revisited as well?

Sorry for lengthy (but hopefully not messy) discussion, and thank you for cooperation.

translators team

On 2019-07-12 15:13, Stamboltsyan Seda wrote:

Your explanation is a mess. What you have explained about hy_AM is the

"For hy_AM/hye_AM the Institute of Language and Ministry of Education
of RA have not yet made the official decision. There is an ongoing
work on unified orthography, after completion of which, it will also
be implemented under this code. For now we will use either IR or RU
variant for this (subject to discussion with the min-edu)."

There is NO "ongoing work on unified orthography", as you say. And
hy_AM has been used for all these years for the Eastern Armenian (that
is, the main language of ARMENIA) with the main orthography used in
Armenia. You write: "For now we will use either IR or RU variant for
this". Really? Who has decided that? Have you asked the opinion of all
the other Armenians of Armenia who are going to use LibreOffice or any
other application localized for Armenia?

Once again: the locale name hy_RU for Armenian of ARMENIA is not
correct, whether it is used by your organization or some others also.
A full stop. Don't attach the name of Russia to the Armenian of
Armenia. And there is NO separate Armenian for the Armenians of
Russia, which means there just can't be any separate locale for
Armenian used in Russia.

Please, don't insist on the wrong decision of minority (like you)
against the already established and correct hy_AM.


12.07.2019, 14:42, "ԻԴ | Սամվել Հարությունյան"

On 2019-07-12 13:08, Stamboltsyan Seda wrote: I have read that
dialogue, but adding or changing locales is not my

So far, in all programs localized for Armenia the locale used has
hy_AM. If you have decided to change that to hy_RU (a horrible
decision due to that RU part, which indicates Russia, and we are
part of Russia, mind it), then what is hy_AM for?

I don't know if it is possible to merge your and my translations.
like to first have a look at your translation.


12.07.2019, 12:56, "ԻԴ | Սամվել Հարությունյան"
On 2019-07-11 20:21, Stamboltsyan Seda wrote: Hi, Samvel

I don't know what your translation is and whether it can be merged
with mine. You should've registered in Pootle and made known about
your work so that I might not do the work I'm doing now if we were
translating in the same language and in the same orthography.
if you have translated in the same Armenian language and the same
orthography, then my translation becomes redundant and I have lost
enormous amount of time. My translation is in the Eastern Armenian
(the main language used in the Republic of Armenia) and in the main
(reformed) orthography used in Armenia.

So, you are free to make any decision with the Pootle
The most important thing here is that we may have a full Armenian
localization of LibreOffice. If you have done it, that's great, and
I'll stop translating if your translation is in the same language


11.07.2019, 16:35, ""
There are 4 types of Armenian locales added to Loffice. We've
translated hy-RU, and now we are translating hy-IR(Armenian with
classical orthography). Please, read this

class="quote" style="line-height: 1.5"><br><br>-------- Original
Message --------<br>Subject: Re: [libreoffice-l10n] Add hy-RU to
Pootle translation server<br>From: sophi
<><br>To: ԻԴ | Սամվել

<br><br><br type="attribution"><blockquote class="quote"
style="margin:0 0 0 .8ex;border-left:1px #ccc
solid;padding-left:1ex">Hi Samvel,<br>Le 11/07/2019 à 09:15, ԻԴ
Սամվել Հարությունյան a écrit :<br>> Hi,<br>>
We've started translating Libreoffice-6.0 at march 2018 in
Armenian<br>> (hy-RU) and finished a few days ago. Now we try apply
it on libreoffice<br>> 6.2 or 6.1 but a part of UI isn't
translated. We haven't upload it<br>> Pootle yet. Please add hy-RU
language to your server. Please help us<br>> make translation of
latest version without doing whole work again.<br><br>Thanks for
your work! Armenian is already in
you in contact with Seda already, he is administrator of
your<br>language in Pootle?<br>Cheers<br>Sophie<br><br>--
+33683901545<br>IRC: sophi<br>Release coordinator<br>The Document
To unsubscribe e-mail to:
Posting guidelines + more:
List archive:
Privacy Policy:
Hi, Seda.
We've translated in the Eastern Armenian language with the main
(reformed) orthography but it should be under hy-RU not hy. Please
this dialogue too.
But our translation is for Loffice 6.0. Can we merge .po files to
Regards, Samvel
Samvel Harutyunyan

Dear Seda, dear Sophi,
in that dialogue it's explained in details why we call these hy-RU and
hy-IR. Is it possible to upload translations of LOffice 6.0 to Pootle
translation of 6.2 or 6.1 merging with yours or without? Here's our
completed work (.po files of LOffice 6.0 in the Soviet Armenian
Samvel Harutyunyan

Սամվել Հարությունյան

«Իրական Դպրոց»

To unsubscribe e-mail to:
Posting guidelines + more:
List archive:
Privacy Policy:


Privacy Policy | Impressum (Legal Info) | Copyright information: Unless otherwise specified, all text and images on this website are licensed under the Creative Commons Attribution-Share Alike 3.0 License. This does not include the source code of LibreOffice, which is licensed under the Mozilla Public License (MPLv2). "LibreOffice" and "The Document Foundation" are registered trademarks of their corresponding registered owners or are in actual use as trademarks in one or more countries. Their respective logos and icons are also subject to international copyright laws. Use thereof is explained in our trademark policy.