Workflow between dev, UX and l10n teams

projects
#21

Review strings in context.

Whoever volunteers for this task will need to go through _all_ of the
existing help, UI, and other things, before reviewing strings when they
are changed.

The task requires:
* Copy editing;
* Line editing;
* Proof reading;
amongst other editing tasks.

FWIW, this also means that the l10n, a11y, and i18n teams will be dumped
with a slew of changes that might, but probably won't affect their
existing translation, but will still need to be verified to ensure that
their translations, etc. are not broken.

BTW, does anybody know where the *current* _LibreOffice Manual of
Style_ can be obtained from?

jonathon

#22

If you need to review *all* help & UI, I think it maps to an equivalent of a 500 or more page handbook.

But you don't. L10n only are only asking for review of strings when they are being changed.

Review strings in context.

Whoever volunteers for this task will need to go through _all_ of the
existing help, UI, and other things, before reviewing strings when they
are changed.

So basically there's a steep learning curve, but once someone has an
active knowledge of the current text, then they should be able to do
work in small deltas. As long as there's clear documentation about
getting up to speed (and the potential time to do so), the workflow
seems plausible.

The task requires:
* Copy editing;
* Line editing;
* Proof reading;
amongst other editing tasks.

Yup, sounds challenging.

FWIW, this also means that the l10n, a11y, and i18n teams will be dumped
with a slew of changes that might, but probably won't affect their
existing translation, but will still need to be verified to ensure that
their translations, etc. are not broken.

I keep on hearing about these big changes. Some of them sound
scriptable, but have there been some that are not? Aside from the
bulk-changes, how many string additions/modifications/etc.. are there
on a weekly or monthly basis?

BTW, does anybody know where the *current* _LibreOffice Manual of
Style_ can be obtained from?

Once we find it, let's add a redirect here:
https://wiki.documentfoundation.org/Manual_of_style

(Or it can live there, if it doesn't have a good home yet! :slight_smile:

If it's more of an official-ish document, perhaps this would be a better home:
https://wiki.documentfoundation.org/TDF/Manual_of_style

Best,
--R

#23

So basically there's a steep learning curve,

I wouldn't describe it as "a steep learning curve" as much as it is
ensuring that the current text is grammatically correct en_US, with no
spelling errors, _and_ conforms to the conventions in the Style Manual.

Rephrased: The person has to translate everything into en_US, then
copyedit everything.

but once someone has an active knowledge of the current text, then

they should be able to do work in small deltas.

In theory, once everything is in en_US, and conforms to the style
manual, then the only "knowledge" required, will be to read the material
once or twice, before being able to work on small deltas.

As long as there's clear documentation about getting up to speed (and

the potential time to do so), the workflow seems plausible.

That initial translation & copyedit is there, purely because of a number
of minor issues. Things that 99.99% of the users probably won't notice,
but overall detract from the project. The things that one is not
conscious of, but nonetheless have a negative impact.

I keep on hearing about these big changes. Some of them sound scriptable, but have there been some that are not?

Presentation markup is usually scriptable.

Vocabulary, spelling, syntax, and grammatical changes are not
scriptable. (Well they can be, but you end up with "invisible, insane"
for "out of sight, out of mind".)

If it's more of an official-ish document, perhaps this would be a better home:
https://wiki.documentfoundation.org/TDF/Manual_of_style

My sense is that whilst Sun wanted the project to use it, it's usage was
honoured by the breach thereof.

jonathon

#24

Am I right in reading into this, that master is using American English?
And if so, why? Seeing as LibreOffice is, at heart, a European program
surely it should be using English?

Like British English? RP? Let's be specific here...

What proportion of developers are native American speakers?

Not that many. It would be great to see more involvement from the US,
but I think that promoting the "this is a European Project" attitude
can really hurt those numbers. LibreOffice is a global project: No one
country or continent should try to claim it for itself.

Bear in mind that most English variants use English spelling, not
American spelling.

I think the phrase "American English spelling" is clearer -- there are
lots of languages spoken here across the pond, so the phrase "American
spelling" is ambiguous.

At the end of the day, not enforcing en_us as a translation means that
the majority of us (including those of us that speak English rather than
American as our native language) are forced to suffer pain as the
foundations are messed up underneath us.

Whoa there, cowboy! (or whatever the British equivalent is) I think
that British, American, Canadian, etc.. English are all pretty
similar, so while I agree that we might have our little differences
about an extra 'u' in color, or whether the big vehicle that picks up
the trash is a Lorry or a Truck, it's not a big deal compared to the
diff between the Englishes and French or Spanish.

And by allowing that *minority*
to avoid suffering, they are enabled to cause unnecessary pain without
even realising what they are doing!

*facepalm*

I know that you're just getting some stuff off your chest, and sure, I
get it: languages can be tough. So we get have a couple beers, find
the vertias in the vino, and start speaking French (wait, maybe that's
just what I do). More seriously, I'm trying to get people interested
in LibreOffice in the US, and it's really important for us to make the
project welcoming to users and new contributors.

You want to propose some changes? Sure, great plan. But please check
that your method of delivery doesn't paint the Americans as the
outsiders and buffoons of your diatribe, because the reality is that
we really don't have much going on in the US yet, and there's already
a hesitancy to interact with what is perceived as aloof Europeans. I
think that growth in the US has the potential to give a ton back to
the LibreOffice community in Development, Documentation, QA, and so
forth, but we need to go the extra mile there, not tell people that,
before they've opened a single spreadsheet or triaged a single bug,
they are somehow (?) "causing pain."

The rule should be simple. Any changes of meaning can be edited directly
in master. If it's non-native English, and poor at that such as it's
hard to comprehend then it can be corrected in master. If it's clear
comprehensible English, whether English or Strine or American or
International or whatever, then it's off-limits for changes to master,
and has to be done in Pootle or whatever as a localisation.

I like the general idea, but I am concerned about the feasibility. Notes:

1) will inconsistency of nouns (e.g. color vs. colour), inconsistency
of grammar, etc.. within the sources in master make translation harder
for the native-lang teams?

2) What will the language be for builds w/o langpacks? Just a generic
'English'? (maybe we can call it "LibreOffice English" :slight_smile:

3) Who's going to step up to maintain en_US? (I'd love to help, but
I'm working tons of hours as it is)

Cheers,
--R

#25

Hi Jonathon,

2015.01.27 23:15, jonathon wrote:

>> If you need to review *all* help & UI, I think it maps to an

equivalent of a 500 or more page handbook.

> But you don't. L10n only are only asking for review of strings when

they are being changed.

Review strings in context.

Whoever volunteers for this task will need to go through _all_ of the
existing help, UI, and other things, before reviewing strings when they
are changed.

The task requires:
* Copy editing;
* Line editing;
* Proof reading;
amongst other editing tasks.

FWIW, this also means that the l10n, a11y, and i18n teams will be dumped
with a slew of changes that might, but probably won't affect their
existing translation, but will still need to be verified to ensure that
their translations, etc. are not broken.

I really don't see a revision of all existing strings as a requirement
to start reviewing newly added ones. Of course, it would be beneficial,
but not at all a requirement. You don't need to read a 500-pages worth
of text to tell whether or not a certain string is clear, concise and
grammatically, syntactically and typographically correct. Especially if
you are a native English speaker and have a style guide at hand.

Rimas

#26

Am I right in reading into this, that master is using American English?
And if so, why? Seeing as LibreOffice is, at heart, a European program
surely it should be using English?

Okay, maybe I'm being a little facetious here, but I do get very fed up
when people assume that "English" means American English, and not English.

Surely it would make a lot of sense to state that "Master uses
international English (ie any well-understood variant), and for local
consistency en_gb, en_us, en_au etc have to translate it".

What proportion of developers are native American speakers?

Bear in mind that most English variants use English spelling, not
American spelling. Most non-native speakers of English (even very good
speakers) "don't get" English tenses very well. Likewise, most
non-native speakers use odd grammar and word order - very comprehensible
but a dead giveaway that they are non-native.

At the end of the day, not enforcing en_us as a translation means that
the majority of us (including those of us that speak English rather than
American as our native language) are forced to suffer pain as the
foundations are messed up underneath us. And by allowing that *minority*
to avoid suffering, they are enabled to cause unnecessary pain without
even realising what they are doing!

The rule should be simple. Any changes of meaning can be edited directly
in master. If it's non-native English, and poor at that such as it's
hard to comprehend then it can be corrected in master. If it's clear
comprehensible English, whether English or Strine or American or
International or whatever, then it's off-limits for changes to master,
and has to be done in Pootle or whatever as a localisation.

Cheers,
Wol

#27

I really don't see a revision of all existing strings as a requirement to start reviewing newly added ones.

At some point in time that review has to be done. To minimize the
overall workload, it is easier, and simpler, to do it before reviewing
newly added strings, than afterwards. (For starters, doing it afterwards
means having to review those newly added strings at least twice, and
maybe thrice.)

Especially if you are a native English speaker and have a style guide

at hand.

Just as the English language has never met it word that it has not
adopted as it's own, so it has never met a grammatical construct that it
has not adapted and mutilated. One direct consequence of both those
facets of acquisition, is that it is incredibly difficult to write a
sentence in English that is grammatically incoherent, but extremely easy
to write a sentence that grammatically means the opposite of what was
intended.

IOW, that certain string might be "clear, concise and
grammatically, syntactically and typographically correct", but mean
something other than intended, because the vocabulary is usually used to
mean something else elsewhere.

BTW, when you say "style guide", which specific one do you mean?

jonathon

#28

PS the current setup is not foolproof either as we sometimes get really
bad strings, linguistically bad that is.

If this is such a concern, then why don't we set up a panel of experiences
localizers who are willing to help developers judge if a change is semantic
or cosmetic before we land them on l10n in general?

Michael

+1 to both your comments, Michael.

Sgrìobh Jan Holesovsky na leanas 27/01/2015 aig 14:16:

be deciding if a change should be applied in the sources (ie. it is a
change needed for all languages) and what is just making the original
more consistent? And again - what to do if the person mis-judges?

And thank you to you, Kendy (aka Jan Holesovsky), for answering my

"why". I do see that it is a complex matter.

#29

I really don't see a revision of all existing strings as a

requirement to start reviewing newly added ones.

At some point in time that review has to be done. To minimize the
overall workload, it is easier, and simpler, to do it before reviewing
newly added strings, than afterwards. (For starters, doing it
afterwards
means having to review those newly added strings at least twice, and
maybe thrice.)

You're right, but if the choice is between no reviews at all and reviews of new strings only, which would you choose? It's go for the latter.

Especially if you are a native English speaker and have a style guide

at hand.

Just as the English language has never met it word that it has not
adopted as it's own, so it has never met a grammatical construct that
it
has not adapted and mutilated. One direct consequence of both those
facets of acquisition, is that it is incredibly difficult to write a
sentence in English that is grammatically incoherent, but extremely
easy
to write a sentence that grammatically means the opposite of what was
intended.

IOW, that certain string might be "clear, concise and
grammatically, syntactically and typographically correct", but mean
something other than intended, because the vocabulary is usually used
to
mean something else elsewhere.

Let's add "semantically correct" or "contextually correct" to my list of requirements then. :slight_smile:

BTW, when you say "style guide", which specific one do you mean?

The one you're looking for, assuming it exists. If not, or could be a combination of Gnome HIG and any American English style guide we (the LibO community) would deem acceptable and meeting our needs (e.g. The Chicago Manual of Style).

#30

I still have the one for French but it's copyrighted Sun anyway (from
2006). Gnome HIG contains a lot of information that we can use easily.

Cheers
Sophie

#31

Hi again,

BTW, when you say "style guide", which specific one do you mean?

The one you're looking for, assuming it exists. If not, or could be a
combination of Gnome HIG and any American English style guide we (the
LibO community) would deem acceptable and meeting our needs (e.g. The
Chicago Manual of Style).

In fact, I just thought that it doesn't even have to be a formal manual: if somebody would be willing to oversee style consistency in our strings, and that style would look acceptable by our en-US users, then why not? Especially if that person would be willing to formalize these rules into a written style manual along the way.

#32

Hi again,

BTW, when you say "style guide", which specific one do you mean?

The one you're looking for, assuming it exists. If not, or could be a
combination of Gnome HIG and any American English style guide we (the
LibO community) would deem acceptable and meeting our needs (e.g. The
Chicago Manual of Style).

In fact, I just thought that it doesn't even have to be a formal manual: if somebody would be willing to oversee style consistency in our strings, and that style would look acceptable by our en-US users, then why not? Especially if that person would be willing to formalize these rules into a written style manual along the way.

--
Rimas

This document may be of interest:
https://obriend.fedorapeople.org/WritingStyleGuide/
It's only recently (last year) been open sourced and made public.

#33

I am not sure I understand you here (to me, the "otherwise" part reads: "if there is no way to script changes, wait until there is a script available," which would not make sense).

When talking about (developer-side) scripting, is it actually OK to commit modifications to the translations in the translations git sub-repo? My understanding was that such modifications would be overwritten by the next "import commit" (as typically done by Andras, AFAIU from some Pootle database).

#34

- if there is a way to script changes, script them otherwise wait until
there is a script available to commit them

I am not sure I understand you here (to me, the "otherwise" part reads:
"if there is no way to script changes, wait until there is a script
available," which would not make sense).

Sorry for being unclear, I mean if scripting is possible but the
commiter don't know how to write the script, or have no time for it,
wait until somebody else write it. Of course, if it's no scriptable,
then no need to wait for a script :slight_smile:

When talking about (developer-side) scripting, is it actually OK to
commit modifications to the translations in the translations git
sub-repo? My understanding was that such modifications would be
overwritten by the next "import commit" (as typically done by Andras,
AFAIU from some Pootle database).

I don't know, maybe Andras or Rimas will.

Cheers
Sophie

#35

Am I right in reading into this, that master is using American English?
And if so, why? Seeing as LibreOffice is, at heart, a European program
surely it should be using English?

Like British English? RP? Let's be specific here...

I mean, English like she is spoke in ENGLAND. There's no such language
as British English, true English is the majority language for the
*southern* end of Britain, and many places elsewhere because the English
have migrated, but it really grates when furriners (I guess you're not
British, I can't tell) assume that everybody here speaks the same
language. And if you're going to incorrectly call it "British English",
then actually "English English" would be far more accurate.

Yes, language is a complex matter, but as I like to put it, "In Britain
the Saxons speak English, the Angles speak Scots, and the Scots speak
Gaelic". It's a mess, agreed, but that's no reason to make the mess even
bigger by using completely bogus descriptions.

(And by sounding off like this, I've validated your comments further
down :slight_smile:

What proportion of developers are native American speakers?

Not that many. It would be great to see more involvement from the US,
but I think that promoting the "this is a European Project" attitude
can really hurt those numbers. LibreOffice is a global project: No one
country or continent should try to claim it for itself.

No I'm not trying to claim that at all. I'm simply saying that the
cultural norms of the project are not American, and we're quite happy to
make them welcome, but I don't want to make life hard for the majority,
just to appease a minority who may - OR MAY NOT - decide to join the party.

Bear in mind that most English variants use English spelling, not
American spelling.

I think the phrase "American English spelling" is clearer -- there are
lots of languages spoken here across the pond, so the phrase "American
spelling" is ambiguous.

At the end of the day, not enforcing en_us as a translation means that
the majority of us (including those of us that speak English rather than
American as our native language) are forced to suffer pain as the
foundations are messed up underneath us.

Whoa there, cowboy! (or whatever the British equivalent is) I think
that British, American, Canadian, etc.. English are all pretty
similar, so while I agree that we might have our little differences
about an extra 'u' in color, or whether the big vehicle that picks up
the trash is a Lorry or a Truck, it's not a big deal compared to the
diff between the Englishes and French or Spanish.

I'd be careful here !!! As a European, I really think the official
language should be Spanglianese! (That is, Spanish/Portuguese/Italian).
Those three are effectively modern Latin, are with some difficulties
mutually comprehensible, and are the MAJORITY FIRST language. What would
that do to encourage the Americans in? :slight_smile:

(And I say that as a Brit. Most of my countrymen would be absolutely
horrified by the idea :slight_smile:

And by allowing that *minority*
to avoid suffering, they are enabled to cause unnecessary pain without
even realising what they are doing!

*facepalm*

I know that you're just getting some stuff off your chest, and sure, I
get it: languages can be tough. So we get have a couple beers, find
the vertias in the vino, and start speaking French (wait, maybe that's
just what I do). More seriously, I'm trying to get people interested
in LibreOffice in the US, and it's really important for us to make the
project welcoming to users and new contributors.

You want to propose some changes? Sure, great plan. But please check
that your method of delivery doesn't paint the Americans as the
outsiders and buffoons of your diatribe, because the reality is that
we really don't have much going on in the US yet, and there's already
a hesitancy to interact with what is perceived as aloof Europeans. I
think that growth in the US has the potential to give a ton back to
the LibreOffice community in Development, Documentation, QA, and so
forth, but we need to go the extra mile there, not tell people that,
before they've opened a single spreadsheet or triaged a single bug,
they are somehow (?) "causing pain."

Look at it from the other side. You're telling us Europeans that we have
to do it the American way. It comes over far too much that the Americans
think their way is the only way and it really upsets a lot of people.
That's why so many cultures fear and hate America - they see it as a
direct threat to them. Certainly I see America as a serious threat to my
British way of life ...

I've got no problem whatsoever with welcoming Americans. What I do have
a problem with is them demanding that I become "more American", because
not only do I not want to, I absolutely positively hate the idea!

The rule should be simple. Any changes of meaning can be edited directly
in master. If it's non-native English, and poor at that such as it's
hard to comprehend then it can be corrected in master. If it's clear
comprehensible English, whether English or Strine or American or
International or whatever, then it's off-limits for changes to master,
and has to be done in Pootle or whatever as a localisation.

I like the general idea, but I am concerned about the feasibility. Notes:

1) will inconsistency of nouns (e.g. color vs. colour), inconsistency
of grammar, etc.. within the sources in master make translation harder
for the native-lang teams?

Why should it? English is a ployglot language. A good speaker has to be
able to understand Strine, Texas, Scouse, New Yorker, Geordie, Cannuck
etc etc. And decent written English (of whichever variant) is unlikely
to be a problem. Now if you want to throw in Pidgin that's a different
matter !! :slight_smile:

(And as a Brit, you're expecting me to understand American. What's that
saying? "Sauce for the goose is sauce for the Gander"? If you want me to
understand American, I'll demand you speak Scouse!!! :slight_smile:

2) What will the language be for builds w/o langpacks? Just a generic
'English'? (maybe we can call it "LibreOffice English" :slight_smile:

As someone else said, maybe we shouldn't have one! Or the default build
just includes en_us as standard.

3) Who's going to step up to maintain en_US? (I'd love to help, but
I'm working tons of hours as it is)

The same people who are causing all the grief for everybody else by
currently translating/changing all the strings in master? Surely there's
no difference to the amount of work in translating en_us, as there is to
translating master?

Cheers,
--R

Cheers,
Wol

#36

Hi Stephan,

2015.01.28 11:20, Stephan Bergmann wrote:

When talking about (developer-side) scripting, is it actually OK to
commit modifications to the translations in the translations git
sub-repo? My understanding was that such modifications would be
overwritten by the next "import commit" (as typically done by Andras,
AFAIU from some Pootle database).

The process as I see it would be somewhat like the following: when we
have a big enough string change, which can be scripted coming up, it
should be announced at least a few days in advance, that on day X time
Y, this change will land. Localizers should be allowed to choose whether
or not they want that particular big automatic change transparently
ported to their locales, with a sane default for those who don't voice
their choice by deadline (I suppose that usually the default should be
to perform the change for them as well).

On day X time Y, we close down the affected Pootle project, push its
localizations into git, then somebody who's in charge checks them out of
git and runs the script. When the script finishes its work, the
resulting files are committed back to git, imported back to Pootle and
the project is re-opened for translation. Once that is done, an
announcement should be sent to the L10n list with huge thanks for
everyone's patience and kudos to everybody involved in the process. And
we all live happily ever after. :slight_smile:

Possible risks that I came up with:
* The process of exporting files from Pootle or importing them back
might take hours
    - I don't expect localizers to be too angry about that, because they
can do other stuff meanwhile (such as enjoy their Real Life or work on
other projects).
* The scripts might be buggy
    - Obviously, each time they should be tested in advance with at
least some real data and their result should be validated before committing.
* Some localizers might be too late to the train with their changes
    - Well, first of all, they shouldn't be, but then we could also
have some buffer timeframe to cope with this issue.

On the bright side, I hope the massive changes we are talking about here
will be less and less frequent, making this issue less and less
relevant. From my understanding, we've already changed three dots with
ellipses and straight quotes with curly ones, there shouldn't be much
more typography to improve on, is there? :slight_smile:

Rimas

#37

On day X time Y, we close down the affected Pootle project, push its
localizations into git, then somebody who's in charge checks them out of
git and runs the script. When the script finishes its work, the
resulting files are committed back to git, imported back to Pootle and
the project is re-opened for translation. Once that is done, an
announcement should be sent to the L10n list with huge thanks for
everyone's patience and kudos to everybody involved in the process. And
we all live happily ever after. :slight_smile:

[...]

* The scripts might be buggy
     - Obviously, each time they should be tested in advance with at
least some real data and their result should be validated before committing.

Yeah, its vital that the script will be run in a way that can be tried locally and in advance by any script-writing developer (i.e., that the script will ultimately be run on the git data, not on some pootle data).

On the bright side, I hope the massive changes we are talking about here
will be less and less frequent, making this issue less and less
relevant. From my understanding, we've already changed three dots with
ellipses and straight quotes with curly ones, there shouldn't be much
more typography to improve on, is there? :slight_smile:

Typographic changes should rarely be scriptable across all locales anyway, I guess. (Even the ellipsis change might not have been, given there's not only U+2026 HORIZONTAL ELLIPSIS but at least also U+0EAF LAO ELLIPSIS and U+1801 MONGOLIAN ELLIPSIS.)

#38

This has always been a clear as mud to me as to what the *current*
translation workflow is and how as a developer I can fix a translation.

e.g. in the past changing the "Letter" size translation in Spanish to
"Oficio" instead of the literal translation was a pain. And right now I
want to fix a gadzillion Indic translations short-cuts to ascii chars
and not characters that only available via IM. What I want to do is to
commit to the translations git repo and forget about it. Does that
work ?

C.

#39

Hi Caolán, *,

e.g. in the past changing the "Letter" size translation in Spanish to
"Oficio" instead of the literal translation was a pain. And right now I
want to fix a gadzillion Indic translations short-cuts to ascii chars
and not characters that only available via IM. What I want to do is to
commit to the translations git repo and forget about it. Does that
work ?

Nope, as on the next export from pootle those changes will be overridden again.

The changes need to be done in pootle. (not necessarily via web-UI,
that would be tedious, but the change needs to be reflected in pootle
to "stick").

But as some languages use offline translation, even doing the change
in pootle might be undone when teams just upload their local copy
again without bothering to check for updates that were done in pootle.

ciao
Christian

#40

Hi :slight_smile:
That is an extremely good question.

Even if this thread doesn't result in anything else i hope that more
people in the LibreOffice community DO ask the L10n team for their
thoughts on issues like either of the 2 main questions Caolan is
asking. I think even just that would be a huge step forwards and it
is very much appreciated. :)) Thanks Caolan! :slight_smile:

Sorry i don't have an answer to the actual questions though! :frowning:
Apols and regards from
Tom :slight_smile:

Impressum (Legal Info) | Datenschutzerklärung (Privacy Policy)   Content on this site is licensed under a Creative Commons Attribution Share Alike 3.0 license.