Re: [libreoffice-l10n] Follow-up on en_US changes

2014-12-04 Thread Sophie
Hi Jesper,
Le 04/12/2014 00:58, Jesper Hertel a écrit :
 Bonsoir Sophie,
 
 2014-12-01 14:57 GMT+01:00 Sophie gautier.sop...@gmail.com:
 
 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. :-)
 
 
 if yes, I'll open a ticket on Redmine.


 Très bien, Sophie!

merci :)

Cheers
Sophie

-- 
Sophie Gautier sophie.gaut...@documentfoundation.org
Tel:+33683901545
Co-founder - Release coordinator
The Document Foundation

-- 
To unsubscribe e-mail to: l10n+unsubscr...@global.libreoffice.org
Problems? http://www.libreoffice.org/get-help/mailing-lists/how-to-unsubscribe/
Posting guidelines + more: http://wiki.documentfoundation.org/Netiquette
List archive: http://listarchives.libreoffice.org/global/l10n/
All messages sent to this list will be publicly archived and cannot be deleted


Re: [libreoffice-l10n] Follow-up on en_US changes

2014-12-04 Thread Sveinn í Felli

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

Bonsoir Sophie,

2014-12-01 14:57 GMT+01:00 Sophie gautier.sop...@gmail.com:


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. :-)


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.


--
To unsubscribe e-mail to: l10n+unsubscr...@global.libreoffice.org
Problems? http://www.libreoffice.org/get-help/mailing-lists/how-to-unsubscribe/
Posting guidelines + more: http://wiki.documentfoundation.org/Netiquette
List archive: http://listarchives.libreoffice.org/global/l10n/
All messages sent to this list will be publicly archived and cannot be deleted


Re: [libreoffice-l10n] Follow-up on en_US changes

2014-12-04 Thread Sophie
Hi Sveinn,
Le 04/12/2014 09:21, Sveinn í Felli a écrit :
 Þann mið  3.des 2014 23:58, skrifaði Jesper Hertel:
 Bonsoir Sophie,

 2014-12-01 14:57 GMT+01:00 Sophie gautier.sop...@gmail.com:

 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. :-)
 
 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 :)
 
 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

-- 
Sophie Gautier sophie.gaut...@documentfoundation.org
Tel:+33683901545
Co-founder - Release coordinator
The Document Foundation

-- 
To unsubscribe e-mail to: l10n+unsubscr...@global.libreoffice.org
Problems? http://www.libreoffice.org/get-help/mailing-lists/how-to-unsubscribe/
Posting guidelines + more: http://wiki.documentfoundation.org/Netiquette
List archive: http://listarchives.libreoffice.org/global/l10n/
All messages sent to this list will be publicly archived and cannot be deleted


Re: [libreoffice-l10n] Follow-up on en_US changes

2014-12-03 Thread Jesper Hertel
Bonsoir Sophie,

2014-12-01 14:57 GMT+01:00 Sophie gautier.sop...@gmail.com:

 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. :-)


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


Très bien, Sophie!


 Cheers
 Sophie


Santé
Jesper

-- 
To unsubscribe e-mail to: l10n+unsubscr...@global.libreoffice.org
Problems? http://www.libreoffice.org/get-help/mailing-lists/how-to-unsubscribe/
Posting guidelines + more: http://wiki.documentfoundation.org/Netiquette
List archive: http://listarchives.libreoffice.org/global/l10n/
All messages sent to this list will be publicly archived and cannot be deleted


Re: [libreoffice-l10n] Follow-up on en_US changes

2014-12-03 Thread Yury Tarasievich
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

On 12/04/2014 02:58 AM, Jesper Hertel wrote:

2014-12-01 14:57 GMT+01:00 Sophie gautier.sop...@gmail.com:

...

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

--
To unsubscribe e-mail to: l10n+unsubscr...@global.libreoffice.org
Problems? http://www.libreoffice.org/get-help/mailing-lists/how-to-unsubscribe/
Posting guidelines + more: http://wiki.documentfoundation.org/Netiquette
List archive: http://listarchives.libreoffice.org/global/l10n/
All messages sent to this list will be publicly archived and cannot be deleted


Re: [libreoffice-l10n] Follow-up on en_US changes

2014-12-03 Thread Rimas Kudelis
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. :-)

Rimas

On 2014 m. gruodis 4 d. 08:06:12 EET, Yury Tarasievich 
yury.tarasiev...@gmail.com wrote:
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

On 12/04/2014 02:58 AM, Jesper Hertel wrote:
 2014-12-01 14:57 GMT+01:00 Sophie gautier.sop...@gmail.com:
...
 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

-- 
To unsubscribe e-mail to: l10n+unsubscr...@global.libreoffice.org
Problems?
http://www.libreoffice.org/get-help/mailing-lists/how-to-unsubscribe/
Posting guidelines + more:
http://wiki.documentfoundation.org/Netiquette
List archive: http://listarchives.libreoffice.org/global/l10n/
All messages sent to this list will be publicly archived and cannot be
deleted

--
Rimas

-- 
To unsubscribe e-mail to: l10n+unsubscr...@global.libreoffice.org
Problems? http://www.libreoffice.org/get-help/mailing-lists/how-to-unsubscribe/
Posting guidelines + more: http://wiki.documentfoundation.org/Netiquette
List archive: http://listarchives.libreoffice.org/global/l10n/
All messages sent to this list will be publicly archived and cannot be deleted


[libreoffice-l10n] Follow-up on en_US changes

2014-12-01 Thread 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.

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
-- 
Sophie Gautier sophie.gaut...@documentfoundation.org
Tel:+33683901545
Co-founder - Release coordinator
The Document Foundation

-- 
To unsubscribe e-mail to: l10n+unsubscr...@global.libreoffice.org
Problems? http://www.libreoffice.org/get-help/mailing-lists/how-to-unsubscribe/
Posting guidelines + more: http://wiki.documentfoundation.org/Netiquette
List archive: http://listarchives.libreoffice.org/global/l10n/
All messages sent to this list will be publicly archived and cannot be deleted