Date: prev next · Thread: first prev next last

Hi Michael,
On 07/06/2011 00:19, Michael Münch wrote:
Hi Spohie,

I deleted those parts where we agree.

Am Montag, den 06.06.2011, 18:36 +0300 schrieb Sophie Gautier:
If not the language does not matter and there is no need to translate
und multiply the work with translating all the tests in more than 100

It's important to offer an access to everybody.

Are there any rough estimations how many people are affected that can
not contribute in this technical process because of the need to read
basic English texts? As I said, bugzilla, easy hacks, LibOCon, this
project list, ...

Look at the subscribers on the language mailing lists, quite numerous, this is why we have native language communities for years now, this is their only chance to participate to our project.

When I see what is discussed on the german discuss list (reworking of
the download page) where the non-german speaking community is not aware
of and can not take part in the discussion, and probably similar things
going on on other language mailing lists, I believe we already lose so
much by not using the same language that connects us way to often.

Ha, are you an Esperanto supporter? ;) I agree with you, but there is nothing else we can do than coping with it the best we can. Offering areas where every body can use their skills, whatever they are and whatever the language he uses, it may requires more energy for some of us, but I believe, it's a great benefit for the project.

Litmus becomes unusable and getting statistics gets much
harder as you have to aggregate over all the languages.

I'm following the next generation Mozilla is working on. I think we
won't have more than 15/20 languages at the beginning, so that won't
hurt Litmus so much. But we will be able to improve our process and tooling.

That would easily result in more than 1000 testcases that have some
obscure tagging and categorizing in the testcase summary. If I look into
the mozilla litmus I can just guess why they do not use localized
testcases this way. I believe this is a huge trade-off and not worth it.

Do you have another suggestion, or another tool in mind. I'm open to everything, I didn't find something better at the moment, but I may not be aware of some process/tools more adapted.

Litmus is already complicated enough to use, working around the workflow
to get some localization feature into it that is not cleanly integrated
into the application just makes it worse. I fear that through making it
look more complex we will scare more people away than we reach through
the localizations that first have to written. And by the way all those
users of the languages that are not in your estimated 15/20 languages do
not even have the opportunity.

But I agree to disagree here.

:) As said above, I'm open to any suggestion either on the process or the tool. We are at the beginning so it would be easy to move now, more than later. We have:
- a large community,
- about 100 languages,
- dev versions, betas, RCs,
- several platforms
- manual TCS and VCLTestTool automated tests

All this have to be combined in a fine, easy to use, useful and robust tool, a bit challenging I guess :) Sun did a great job on the last TCM release for QUASTe, but unfortunately, it has never been opensourced...

Kind regards
Founding member of The Document Foundation

Unsubscribe instructions: E-mail to
Posting guidelines + more:
List archive:
All messages sent to this list will be publicly archived and cannot be deleted


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.