-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On 27/01/15 18:06, Rimas Kudelis wrote:
In general, I think it's kind of sloppy (sorry, can't think of a right
word right now) to leave miss-worded strings in the source as they are,
and fix them in a separate locale instead.
The options are to either:
* Accept whatever language_locality that the developer inputs. Teams can
start translation at that point in time;
* Reject all submissions to the code base that are not in
SpecificLanguage_SpecificLocality _and_ conform to style manual criteria;
* Prohibit all translation, until the translation team tasked with
SpecificLanguage_SpecificLocality _and_ conformance to style manual
criteria has completed that for each submission to the code base;
* Accept whatever language_locality the developer inputs, and then allow
one team to correct that, whilst allowing other teams to translate the
material, and then re-translate it, once the errors have been corrected
in the source. This is the current workflow;
(e.g. a dozen or two), I really don't think they deserve all this fuss.
The problem is that in every release, there is something that is found
at the last minute, that requires a change, or correction in en_US, but
may not need to be corrected in any other language, or for any other
locality. However, by making the correction in the source, every other
team has to verify that "Yes, that change had absolutely no effect on
anything we did".
jonathon
* English - detected
* English
* English
<javascript:void(0);>
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
iQIcBAEBAgAGBQJUyC1BAAoJEKG7hs8nSMR7BJoQAJiSp6dgZZ/r9vdD9vx/fArU
H/pLJ2qQRugW0OHxRYoCnyH/dNgJHRaHZKC7ajk9T9S6nia8ib/LEjfn5rFZ3r72
I8dUcRgaESgVMZkhQKt6Ae+fhEIsAORP/bRMky6tJQl1PvYRV3u0FlRAuNYfqcHR
BE9Q+Lzgp56hHc1DSBm/23D5+cTmxLHT/1OSIgAqPetMNHRJGR9P5BKoiKYctDE7
8PayNEPvrCzkNOrkeY3ocC64p9xq1Bhc5l4WSaEZuc7dNpsV0k+zHDU2Bq5cPO63
4O9s8lXEaH6OBHHDdqOtncG66M7XrRnuhqKFhHUsdgmolFIuSSPgubA3OqTg2p4X
AB+uZbFww2ocB3sB1Yx0IftvVHBu5OlR8MFV+c1QgJHe3kEXEaM5Yu/BhOM+unqj
3E4pWzIll1Kp8y/9sMtRZvVxHzzA9xjm8GXEAWaJZ8twNci7jaNbITby/YEmec/g
94Qy/vsj/l7br+DesVGi8EKt1cFAyT/eshoKo2AS7BeLLQsOHVy1rVSz98kCHv2L
bvjoearlbWEN3e+RZxcUoLKufXVDtncn0UoGGcxwO0GqXvyDWgckytqnwtMTNDb0
Fr8wNyJb69YCPWAZMN5gjCTAMCRkpyQlFY0u17DsmTw1XSyTW/4XKLEVr5UL5m6W
twKRda+D6BP5We0xXa+N
=9Rk9
-----END PGP SIGNATURE-----
Context
- Re: Workflow between dev, UX and l10n teams (continued)
Re: [libreoffice-l10n] Re: Workflow between dev, UX and l10n teams · Rimas Kudelis
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.