Le 04/12/2014 09:21, Sveinn í Felli a écrit :
Þann mið 3.des 2014 23:58, skrifaði Jesper Hertel:
2014-12-01 14:57 GMT+01:00 Sophie <email@example.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
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
higher authority, as they become the authoritative source for the rest of
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
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  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
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
Sophie Gautier firstname.lastname@example.org
Co-founder - Release coordinator
The Document Foundation
To unsubscribe e-mail to: email@example.com
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
Impressum (Legal Info)
: 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