[libreoffice-documentation] Help-files: Large-scale 'cosmetic' changes

l10n
#1

Hi,

2015-12-18 09:59, Jan Holesovsky wrote:

But - what about to introduce an 'en_US' translation in the Pootle,
where native speakers could improve the wording without changing the
meaning? Then once per the release cycle, these could be copied back in
a way that it marks no translations fuzzy.

This question keeps popping up, doesn't it...

In my opinion, it's not a good idea.

First of all, I can't see how it helps in the long run: if you plan to
promote the en_US "translation" strings as source at some point, then
they will still be marked fuzzy at that given moment, and you would
still have to tackle that issue either by using some automation, or by
asking all other locales to update their translations. So, the problem
remains there, and the only change is that now you'd have to manage a
new pseudo-translation. And to write a script which promotes these
strings to the base.

On top of that (or if you don't plan to promote en-US strings as
source), I find rather awkward the idea of having "mostly proper
English, but sometimes bastardized by foreign developers" as the base
language. In my opinion, a much better idea would be to hook these
English to-be-localizers into any patch review process which involves
adding new strings. This way incorrect strings would simply not be
introduced into the application, as opposed to being introduced and then
fixed via a weird workaround.

Rimas

#2

Sgrìobh Rimas Kudelis na leanas 18/12/2015 aig 09:19:

This question keeps popping up, doesn't it...

Every time LO (or Mozilla or whoever) decides to go "From This Kind Of String" to "That kind of string" leading to a collective groan.

In my opinion, it's not a good idea.

I still think that while not a heal-all, separating out the source from en-US is a good idea. Admittedly it would require some folk to cross-check changes to en-US to see if those are linguistic/content fixes which need to be merged into the source but there are a LOT more en-US speakers/developers than in many of the other l10n teams, perhaps with the exception of German.

Michael