PS the current setup is not foolproof either as we sometimes get really
bad strings, linguistically bad that is.
If this is such a concern, then why don't we set up a panel of
experiences localizers who are willing to help developers judge if a
change is semantic or cosmetic before we land the
A person who cannot decide if a string change is semantic or cosmetic to
en-US should not be messing around with the string names in the first
place, if you ask me.
Ok so maybe occasionally they might get it wrong. That still produces a
lot LESS workload to fix that landing 2000 cosmetic en-US
As requested by Eike:
All of my past & future contributions to LibreOffice may be licensed
under the MPLv2/LGPLv3+ dual license.
Michael Bauer
--
*Akerbeltz <http://www.faclair.com/>*
Goireasan Gàidhlig air an lìon
Fòn: +44-141-946 4437
Facs: +44-141-945 2701
*Tha Gàid