On 24/11/2010 11:46, Michael Wheatland wrote:
WOW, this is a big reply. Sorry.
I think you may be misinterpreting most if not all of my comments.
On Wed, Nov 24, 2010 at 4:46 PM, Sophie Gautier
Le 2010-11-22 21:10, Michael Wheatland a écrit :
1. Localisation teams will still exist in an ecosystem along side the
development, design, marketing groups.
All communications in these groups will be in native languages, but
others can also contribute to them using auto-translations.
Not ideal, but we don't have enough translators to get them to
translate every conversation on the site.
This is where you are mistaken, this is not about localization, it's about
native language. No localization in these groups is needed concerning their
work on their sites. No Google translation, no Drupal translation, no Pootle
Sorry, I meant local (native language teams). I understand that there
is no need for translations, however there are a lot of discussions on
these lists which would be useful to share, so why shouldn't the
community have translation available for people outside of a native
language group? I am confused by your flat out refusal for the
community to become more transparent and inclusive. Can you clarify
Do you think that somebody for whom French is the second language will
be able to understand my poor English translated by Google or any
automated tool? I'm sorry but I'm sure you understand how it is much
less powerful than discussing the topic on the native language mailing
list and reporting here. This may slow the process in your eyes but will
be much more inclusive than your proposal.
2. As mentioned before the main site will be structured the same way
for all languages. English is not the default translate to-from
language, it is the simply the fallback if a translation is not
No, each language will structure their site as they want. And English is not
a fall back. If the page doesn't exist in the given language of the site, it
doesn't exist at all on any the site.
I think you may be confusing the Silverstripe site with the Drupal
site. In Drupal each native language team can customise their 'native
language' section, but the structure of the main site remains
consistent across languages for quality control reasons.
This is not needed. Why should we get the structure of the "Why" site,
when it's completely irrelevant in several languages and/or countries?
Do not force the groups to be adapted to the structure, it's the
contrary. You're example with Siverstripe is good because what we get
currently in Silverstripe is exactly what we need. Each group has his
own structure and it's what they want. If I want to read what is on the
Japanese site, I'll ask the Japanese group. It has already worked very
well, see how the language community has grown over the years.
The layout and structure of the Drupal site remains constant across
languages, but language specific content can be added to individual
pages if required.
I don't understand the constant part you're speaking about. We may want
for example to have a download page in French absolutely different from
the en_US one, so how do we manage that? Just display it in English on
the en_US part. And the FR site will have it's French page. No need to
exchange one between another.
As I understand it 'international english' is the primary
communication language of the project, so why would we prefer users be
presented with a 404 error rather than the LibreOffice official
default language version if a specific page has not yet been
translated for their native language?
international english is spoken to share the information between all the
groups, but don't see it has the primary communication language. If
there appears to be a 404 error page, then it's a problem with the tool
used, in that case Drupal, because it should be able to handle how the
language groups are used to work and not the contrary.
As I understand it this has been the biggest problem with the
Silverstripe site to date. It seems to be coming along well, but there
is no underlying structure that spans languages. Refer to the
marketing conference call.
It may be an issue for the marketing project I don't know, but not for
the language groups. And don't expect that the marketing page will be
reflected in the language site, they will have their own content for
marketing with their own naming and so on.
You're still thinking that each language group has the same needs,
objectives, size, understanding, etc. It's simply not the case. Most of
the templates used in one country are not useful in another if there is
no human adaptation, this is exactly a good example to show where l10n
Common structure in the main site is very important to ensure that no
languages are second class citizens, especially for common downloads
such as templates and extensions as well as support options.
All that follows looks to be misinterpreted due to this assumption.
ie. if someone in china accesses a page originally written in french
with no other translations available it will display in french.
It's completely stupid, sorry for that. The content of this page may have
absolutely no relevance for the Chinese Group, why should they have our shop
pages displayed. Another example, why should you display the German page
about their Box? it only is relevant for the German Group. Each language
group has its own life and is not shared by the others every time. We are
If an english translation is available it will display in english.
And it's not acceptable for a sake of quality. It will give a very poor
image of our groups.
I am referring to the main site, not the native language groups.
Again, I think misinterpreted due to the mixup between structure in
Drupal as opposed to Silverstripe.
We hope that all translations will be available, if this is the case
you will only see native language.
And it will display a very poor quality, sorry to repeat it. I'm sure
that most of the language teams will tell you the same as I'm saying.
is a chinese translation available it will display in chinese.
It means that there is a fall back for the fall back. It means people
will never get a 404 error instead of content.
There should get not 404 error, this should not be displayed at all.
Yes, this is irrelevant in the Silverstripe site as there is no
structure consistency across languages, but in Drupal it is critically
important for the main site to avoid '404 Page not found'. (does not
apply to native language areas)
So you should consider the main en_US site as the other language sites.
No difference, don't display a 404 error page and don't display content
that doesn't exist in the en_US language.
In terms of the Q&A section, I would expect that there will be a
knowledge base of manually translated questions and answers along side
an ad-hoc section which would be automatically translated. Quality
ad-hoc questions when answered could be moved to the knowledge base
section then manually translated for accuracy. The concept is fluid at
the moment, so if you would like to see any other features please let
Again, the QA team are used to work together, so don't put constraints where
they are not needed.
Not QA, Q&A Questions and Answers, not Quality Assurance.
Oups, sorry, I'm to QA addict here ;-)
Not sure what constraints you were referring to, but we have not
finished consulting with the quality assurance group yet.
They seem pretty happy with what we are doing so far.
Where is it? as a contributor of the QA team I would like to see the
proposal. Be careful also here that some native language teams will
adapt there pages depending on the resources they have, we are not equal
Currently, all this has my absolute veto.
Each steering committee member has veto power?
My veto as a contributing member, sorry, it was not mean as a SC member.
I was not aware of that.
If this is the case we must have implemented bylaws. Can you tell me
where to find them?
Michael, I'm working with the language groups since years and I'm really
aware of their needs. I'm sorry if I seems to overreact or to be very
categorical. This is really essential that the tool adapts itself to the
concept of the native language community ala OOo and not ala Mozilla. It
is a really different approach and we want to keep this one for
LibreOffice. Imagine also that some of us will never use Drupal and will
manage their own forum and all this will look totally different but will
still be the same strong community. I would like to explain that the
tool won't be what will structure the project and the community, it will
only helps to reflect it if it knows how to adapt to it. And if it
doesn't adapt, the team will use another tool.
Can I suggest that you contact me directly if you are confused about
any of these clarifications of clarifications.
I'm speaking with you here :-) The other teams are reading so they are
aware of what I don't understand and I'm sure this will help all of us
to go where we want.
There has already been a lot of consultation and very good work done
by a lot of people on this on the advice of the steering committee
decision for a rapid start Silverstripe site followed by a fully
functioning Drupal community site.
Rapid yes, but provided we are all ok on what is implemented.
All of the work so far has been observed by Florian out Steering
Committee representative whom has given nothing but positive feedback,
and I must say I am very proud of the efforts of the large and growing
Drupal website team.
I'll add the point to our next conf call on Sunday. But as you have
noted you also get the same feedback by Christoph and Cor. And be assure
that my reaction is not to diminish the work you have done, not at all,
I'm aware of the great effort you have provided and I'm very thankful
for it. But the topic is really important to my eyes because it will
have a very big impact on how the native language group will use the tool.
The Drupal path forward and structure was published about a month ago
on the Website section of the wiki with very positive feedback.
Great, but please, believe my experience here and understand the concept
of the native language community as it has always existed, don't try to
adapt it to Drupal. Currently I know that it won't work this way.
Unsubscribe instructions: E-mail to firstname.lastname@example.org
List archive: http://www.libreoffice.org/lists/website/
*** All posts to this list are publicly archived for eternity ***
Re: [libreoffice-website] Update on Drupal Website Progress · Bernhard Dippold
Impressum (Legal Info)
: 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