Þann mið 3.des 2014 23:58, skrifaði Jesper Hertel:
Bonsoir Sophie,
2014-12-01 14:57 GMT+01:00 Sophie <gautier.sophie@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+unsubscribe@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
Context
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.