Follow-up on en_US changes

l10n
#1

Hi all,

Opening a new thread on the changes on the en_US version, I propose to
follow-up on the project@ list so we could associate the developers and
design teams and discuss together how to handle that in our workflow.
Some changes are necessary and the en_US version has to be maintained
too but that shouldn't have an impact or at least, as limited as
possible on the l10n work.

I'm not sure it's the good moment to open the discussion now because we
are all catching dead lines, but I propose to do it on week 2 next year,
after the hard code freeze for 4.4.0.
Is it ok for you all? if yes, I'll open a ticket on Redmine.

Cheers
Sophie

#2

Bonsoir Sophie,

Hi all,

Opening a new thread on the changes on the en_US version, I propose to
follow-up on the project@ list so we could associate the developers and
design teams and discuss together how to handle that in our workflow.
Some changes are necessary and the en_US version has to be maintained
too but that shouldn't have an impact or at least, as limited as
possible on the l10n work.

For some reason I don't completely catch what you are saying, but I guess
it is something along the lines that we should have a specific discussion
forum for the en_US (American English, the "original" text) version? Or
maybe a discussion about whether we should have a separate discussion forum?

I do believe discussing the English strings are somewhat related to the
translation of them, so maybe because of that I fail to see a very sharp
division between them and the localization. The English strings are, in
principle, also a type of localization, I would say. They just have a much
higher authority, as they become the authoritative source for the rest of
the localizations.

I'm not sure it's the good moment to open the discussion now because we
are all catching dead lines,

Yeah, and maybe what I wrote above is in some way also part of that
discussion that we probably should not take now? If so, you don't have to
respond to my comment now.

but I propose to do it

Does "do it" mean start the discussion, or are you referring to something
else?

on week 2 next year,
after the hard code freeze for 4.4.0.

Is it ok for you all?

Fine with me. :slight_smile:

if yes, I'll open a ticket on Redmine.

Très bien, Sophie!

Cheers
Sophie

Santé
Jesper

#3

I may be completely misunderstanding this, but it seems to me the point is the en_US strings should be translations as well. That would put much needed damper on the changes introduced "just because they can be introduced". As a secondary gain, translations are (hopefully) created by folks with at least some native language preparation; right now "master" strings "which anybody can write" -- as I know from my own practice and from this list -- may be awkward in expression and/or convoluted in meaning (fixing which creates more work for everybody).

Yury

...

Some changes are necessary and the en_US version has to be maintained
too but that shouldn't have an impact or at least, as limited as
possible on the l10n work.

I do believe discussing the English strings are somewhat related to the
translation of them, so maybe because of that I fail to see a very sharp
division between them and the localization. The English strings are, in
principle, also a type of localization, I would say. They just have a much
higher authority, as they become the authoritative source for the rest of
the localizations.

...

Yury

#4

IMO bad quality of English strings can be improved by having some l10m teams work on Master (and spotting these bad strings early enough), and that is being discussed in parallel.

Also, perhaps requiring string reviews on patches with new or changed strings could be an option. I'm pretty sure we could find someone to gladly do these reviews within the community. :slight_smile:

Rimas

#5

Hi Jesper,

Bonsoir Sophie,

Hi all,

Opening a new thread on the changes on the en_US version, I propose to
follow-up on the project@ list so we could associate the developers and
design teams and discuss together how to handle that in our workflow.
Some changes are necessary and the en_US version has to be maintained
too but that shouldn't have an impact or at least, as limited as
possible on the l10n work.

For some reason I don't completely catch what you are saying, but I guess
it is something along the lines that we should have a specific discussion
forum for the en_US (American English, the "original" text) version? Or
maybe a discussion about whether we should have a separate discussion forum?

I do believe discussing the English strings are somewhat related to the
translation of them, so maybe because of that I fail to see a very sharp
division between them and the localization. The English strings are, in
principle, also a type of localization, I would say. They just have a much
higher authority, as they become the authoritative source for the rest of
the localizations.

English strings come from different teams in the community, mostly from
developers and UX/Design teams, sometimes QA when they see small things
to fix quickly. The l10n team is the one who review the English strings
and who is the most impacted by their quality (before the user) and the
workload when they are changed.

When we want to discuss something that has an interest for several
teams, we have a cross team list, the projects@ list. I believe that the
developer should be aware, as well as the UX team that if they want to
make large changes to the English string, that will have a huge impact
on the l10n team and they have to take care of how those changes are
applied (spread over the branches, create scripts, etc.)

I'm not sure it's the good moment to open the discussion now because we
are all catching dead lines,

Yeah, and maybe what I wrote above is in some way also part of that
discussion that we probably should not take now? If so, you don't have to
respond to my comment now.

but I propose to do it

Does "do it" mean start the discussion, or are you referring to something
else?

yes, that mean starting the discussion on the projects@list

on week 2 next year,
after the hard code freeze for 4.4.0.

Is it ok for you all?

Fine with me. :slight_smile:

if yes, I'll open a ticket on Redmine.

Très bien, Sophie!

merci :slight_smile:

Cheers
Sophie

#6

IMO bad quality of English strings can be improved by having some
l10m teams work on Master (and spotting these bad strings early
enough), and that is being discussed in parallel.

yes, but I don't want the workload to be only on the l10n team shoulders :slight_smile:

Also, perhaps requiring string reviews on patches with new or changed
strings could be an option. I'm pretty sure we could find someone to
gladly do these reviews within the community. :slight_smile:

+1 I hope to find somebody from the UX team who would be interested in
this task.

Cheers
Sophie

#7

Þann mið 3.des 2014 23:58, skrifaði Jesper Hertel:

Bonsoir Sophie,

Opening a new thread on the changes on the en_US version, I propose to
follow-up on the project@ list so we could associate the developers and
design teams and discuss together how to handle that in our workflow.
Some changes are necessary and the en_US version has to be maintained
too but that shouldn't have an impact or at least, as limited as
possible on the l10n work.

For some reason I don't completely catch what you are saying, but I guess
it is something along the lines that we should have a specific discussion
forum for the en_US (American English, the "original" text) version? Or
maybe a discussion about whether we should have a separate discussion forum?

I read this as 'delaying' the discussion on how to correct source texts (en_US) until after 4.4.0 and do it in a separate thread.

I do believe discussing the English strings are somewhat related to the
translation of them, so maybe because of that I fail to see a very sharp
division between them and the localization. The English strings are, in
principle, also a type of localization, I would say. They just have a much
higher authority, as they become the authoritative source for the rest of
the localizations.

I'd say that catching errors in source texts (en_US) is a vital process of QA for the source code - translators happen to be in the front line for that kind of work.

I'm not sure it's the good moment to open the discussion now because we
are all catching dead lines,

Yes, but... (see below)

Yeah, and maybe what I wrote above is in some way also part of that
discussion that we probably should not take now? If so, you don't have to
respond to my comment now.

but I propose to do it

Does "do it" mean start the discussion, or are you referring to something
else?

on week 2 next year,
after the hard code freeze for 4.4.0.

Is it ok for you all?

Fine with me. :slight_smile:

But, to avoid pissing off all the translators because of typographical corrections (I'm all for it; there are even more types of corrections possible [1] than those which have been mentioned so far...), maybe the good moment is to do this work _before_ setting up next branch in Pootle?

I mean, to batch-replace triple-dots for proper ellipsis in source and in the translations that support it - in the places where UTF-8 is supported - could possibly be done outside of Pootle without giving new fuzzies, isn't it?

Typographical quotes and correction of straight apostrophes are rather only for the source and English derivatives, and should be done without fuzzying the translations. Please.

Is there a better opportunity to do such work than before next branching?

Best regards,
Sveinn í Felli

if yes, I'll open a ticket on Redmine.

Très bien, Sophie!

Cheers
Sophie

Santé
Jesper

[1]: Extermination of double-spaces between sentences is one; lengthy discussions can easily develop on the subject: <http://lists.scribus.net/pipermail/scribus/2014-November/051136.html>
Other topics may be of interest e.g. on difference of typograpy on paper vs. screen.

#8

Hi Sveinn,

Þann mið 3.des 2014 23:58, skrifaði Jesper Hertel:

Bonsoir Sophie,

Opening a new thread on the changes on the en_US version, I propose to
follow-up on the project@ list so we could associate the developers and
design teams and discuss together how to handle that in our workflow.
Some changes are necessary and the en_US version has to be maintained
too but that shouldn't have an impact or at least, as limited as
possible on the l10n work.

For some reason I don't completely catch what you are saying, but I guess
it is something along the lines that we should have a specific discussion
forum for the en_US (American English, the "original" text) version? Or
maybe a discussion about whether we should have a separate discussion
forum?

I read this as 'delaying' the discussion on how to correct source texts
(en_US) until after 4.4.0 and do it in a separate thread.

yes, we won't get developers' attention before the code freeze and they
are concerned by the discussion.

I do believe discussing the English strings are somewhat related to the
translation of them, so maybe because of that I fail to see a very sharp
division between them and the localization. The English strings are, in
principle, also a type of localization, I would say. They just have a
much
higher authority, as they become the authoritative source for the rest of
the localizations.

I'd say that catching errors in source texts (en_US) is a vital process
of QA for the source code - translators happen to be in the front line
for that kind of work.

yes, but it's not only translators who should be involved in the process.

I'm not sure it's the good moment to open the discussion now because we
are all catching dead lines,

Yes, but... (see below)

Yeah, and maybe what I wrote above is in some way also part of that
discussion that we probably should not take now? If so, you don't have to
respond to my comment now.

but I propose to do it

Does "do it" mean start the discussion, or are you referring to something
else?

on week 2 next year,
after the hard code freeze for 4.4.0.

Is it ok for you all?

Fine with me. :slight_smile:

But, to avoid pissing off all the translators because of typographical
corrections (I'm all for it; there are even more types of corrections
possible [1] than those which have been mentioned so far...), maybe the
good moment is to do this work _before_ setting up next branch in Pootle?

the next branch in Pootle will be for 4.5.0 unless we change the
workflow to have it on master. The next source code branching will be
week 2 for 4.4.0 and week 6 for 4.4.1. It's already too late for 4.4.0
but once the branching is done for it, it will be easier to have a cross
teams discussion.

I mean, to batch-replace triple-dots for proper ellipsis in source and
in the translations that support it - in the places where UTF-8 is
supported - could possibly be done outside of Pootle without giving new
fuzzies, isn't it?

yes, I think so :slight_smile:

Typographical quotes and correction of straight apostrophes are rather
only for the source and English derivatives, and should be done without
fuzzying the translations. Please.

Is there a better opportunity to do such work than before next branching?

I agree with you and I hope that we will have something in place before
April.
Cheers
Sophie

#9

Hi :slight_smile:
I think most translations are NOT word-for-word so i suspect that you all
tend to smooth over 'rough' patches. Plus there are a couple of people who
joined this mailing list specifically to help with occasional issues or to
try to help re-explain bits where a concept might not exist in a specific
other language.

A couple years ago there was a few of weeks where there were daily reports
of problems with the English 'original'. So that was when a couple of
people joined this list to help. At the moment that resource is being a
little underutilized, which is ideal.

Ideally the Documentation Team would have a system for proof-reading all
the UX, Wiki, websites, announcements and the in-built help. Sadly they
have always been a very tiny team and most of them don't seem to be able to
cope with almost any of the technical stuff that translators routinely deal
with. So they tend to focus on the Published Guides which use more
traditional work-flows and even that is a bit overwhelming.

Even if they did have the capacity to deal with all the things they would
like to do there would still be individual issues. I'm fairly sure that
every language has some concepts that are not so easy to express in other
languages. So i think we would still need a couple of people to answer
questions about oddities like that.

The people who DO work hard to proof-read and update all the rest
(everything other than the published guides) also tend to be very tiny
teams, over-worked and often seem to be non-native English-speakers. That
is sometimes an advantage, because they tend to know the rules better, but
sometimes makes it tougher to make things smooth.

So, i think we are doing the best we reasonably can - and that we have made
the best use of limited resources. It's not perfect but what is?

Regards from
Tom :slight_smile: