Hi,
2014.12.14 15:04, Tom Davies wrote:
My last "hare-brained" idea was blatantly flawed. Thanks to Yury (i think)
and someone else for shooting it down quickly before it went anywhere! 
Sorry about that!
It sounds like there is scope for a lot of automation. There might already
be ways of doing it.
1. Can fuzzy strings be accepted "en masse", preferably by large-scale
selection? (I'm guessing there isn't at the moment)
2. Is there an "undo"?
3. Can individual strings "undo" to get single strings back to being fuzzy?
Also, is there a way of getting an extremely large selection of strings
grouped in some way so that people can see the whole group had 1 specific
change? Even fairly small groupings might help a bit!
As far as I know, there is no Undo functionality in Pootle. Once you
submit a string, its old version is gone for good. Same goes for
grouping strings by changes: while this might be an interesting idea, I
don't think it is currently possible in Pootle.
And now to my main point (your first question)
As far as I know, Pootle operates on single strings, not on groups. But
even if it did operate on groups, it would be hard to tell whether or
not a particular fuzzy string should be approved without looking at it,
so it wouldn't really help that much. On top of that, it would still
waste someone's time.
I still believe that the right way to implement typography improvements
(and case improvements in most cases) is to transplant such changes to
localized files invisibly. Ideally, it would be done with a prior notice
such as "please upload all your work by day X hour Y so we can base this
migration on your latest work and none of it is being lost".
Same applies to accelerator character change (~ to _).
Even changes like adding a colon at the end of a string (of which people
also complained) should be ported to most locales automatically,
allowing locales to opt-out if they want to do that manually (although I
guess locales should be allowed to opt-out in all cases anyway).
I don't really follow this mailing list too closely, so I might be
wrong, but I would speculate that perhaps the main reason why we ended
up all whining and pointing fingers and sometimes speaking badly of
other people in this thread is the lack of internal communication,
proper planning and preparation. Someone came up with a great idea to
easily improve a massive amount of source strings, but maybe that person
didn't even consider the amount of workload that such change would bring
to the L10n teams. Someone else liked the idea, but did not consider
L10n as well. I can actually relate quite easily to these people – they
are developers, not localizers, it's quite likely that they don't even
know how our L10n process works. So, they liked the idea, and their
changes hit the fan, splashing "typographical nonsense" on everyone.
Had the plans to change such a big amount of strings been communicated
to the localizers well in advance, a red flag would probably have been
raised, and then better preparation (in the form of automatic conversion
scripts) would have been made in anticipation of these changes. Then
everything would be much smoother and we wouldn't waste our time
repeatedly expressing how annoyed and underappreciated we are feeling.
I guess things like these have to be learnt by developers the hard way.
Which is why it's very important that our dissatisfaction with these
issues is communicated to the dev team properly and that they note it
and don't forget it in future. This is also where at least a few L10n
teams working directly on master would help: noticing such unexpected
massive changes early enough should open the door for backing them out
and delaying their re-landing until necessary preparations would be made.
Anyway, I think I've already said all this a couple times before. Time
to sleep.
Cheers,
Rimas
![[TEST] Document Foundation Community](https://communitytest.documentfoundation.org/images/discourse-logo-sketch.png){kind=logo}