Re: [libreoffice-website] Re: Update on Drupal Website Progress
Hi Marc, :-) On Sun, Nov 21, 2010 at 03:24, Marc Paré wrote: > The Design Team also has its own mailist. Can you give the link to subscribe to that list, please? TIA. ;-) David Nelson -- E-mail to website+h...@libreoffice.org for instructions on how to unsubscribe List archives are available at http://www.libreoffice.org/lists/website/ All messages you send to this list will be publicly archived and cannot be deleted
Re: [libreoffice-website] Re: Update on Drupal Website Progress
On Sun, 2010-11-21 at 03:27 +0800, David Nelson wrote: > Can you give the link to subscribe to that list, please? design -at- libreoffice.org you can also get RSS feeds for any of the lists or groups of lists or all lists...via the nabble interface, and most likely other ways also. For instance - New top level emails (not a reply) http://nabble.documentfoundation.org/Design-ft1935996.xml or for all emails http://nabble.documentfoundation.org/Design-f1935996.xml Another RSS feed - for the Announcement list http://nabble.documentfoundation.org/Announce-ft1621702.xml HTH Drew -- E-mail to website+h...@libreoffice.org for instructions on how to unsubscribe List archives are available at http://www.libreoffice.org/lists/website/ All messages you send to this list will be publicly archived and cannot be deleted
Re: [libreoffice-website] Re: Update on Drupal Website Progress
Le 22/11/2010 20:16, Marc Paré a écrit : BTW, a good suggestion that Jean-Sebastien had was to offer a button whereby the member/visitor could either turn on/off the translation tools as well as an offer to translate the page for the site. It would be perfect... -- Unsubscribe instructions: E-mail to website+h...@libreoffice.org List archive: http://www.libreoffice.org/lists/website/ *** All posts to this list are publicly archived for eternity ***
Re: [libreoffice-website] Re: Update on Drupal Website Progress
Hi, :-) Don't be over-optimistic with the results you'll get with machine translation. Sometimes, they're good for a belly laugh, Frequently, they're totally off-target. You'd do *much* better to recruit the support of human translators. 0.2 cents. David Nelson -- Unsubscribe instructions: E-mail to website+h...@libreoffice.org List archive: http://www.libreoffice.org/lists/website/ *** All posts to this list are publicly archived for eternity ***
Re: [libreoffice-website] Re: Update on Drupal Website Progress
Hi Marc! Although I do think that automatic translation might help in some cases, it is unlikely that it provides the outcome that is currently claimed. As I said earlier, if we come to technical terminology within LibO, then all non-domain specific (or aware) translation tools do more harm than they do help. At least, sometimes I enjoy reading those translations :-) Sophie is right when she says, that the communication and the help between the people speaking a certain language (or, being in a certain area) helped to grow what we currently experience as "the community". She is also right, that the approach - and therefore the contents of the documents - varies between all the native lang groups. >From my point-of-view (given the experience within the OOo project), the following approach might combine all the positive effects :-) * Provide the most essential information on LibO and TDF in all languages, derived from the main language English. The content for the other languages should be translated "manually". * Enable the language teams to add own content - independent from the main language English. * For non-critical content, provide a way to translate the given content. I think it would be most helpful for "normal" conversations like in forums or emails. Besides the already stated "button" metaphor, make sure that people are aware of reading a translated text (the rest is an usability problem which can be solved, happy to help here). (Oh, I just saw that Michael did already mention this in another mail. Sorry for sending it another time, but maybe it helps to support his idea.) Sophie, thanks for your input here - I'm sure your great experience will help to make the infrastructure "rock". Also, thanks to Marc and all the other people that drive the infrastructure topic! Cheers, Christoph Am Montag, den 22.11.2010, 14:16 -0500 schrieb Marc Paré: > A good example where such a tool would come in handy is exactly this > thread. How many more people would contribute to this particular > thread is the automatic translation tools allowed them the opportunity > to view/read these threads. OR for that matter how many more people > would participate on the Drupal Website Development Team if the > translation tools would help. -- Unsubscribe instructions: E-mail to website+h...@libreoffice.org List archive: http://www.libreoffice.org/lists/website/ *** All posts to this list are publicly archived for eternity ***
Re: [libreoffice-website] Re: Update on Drupal Website Progress
Thanks all for the input to this concept. I just wanted to clarify a couple of points: 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. 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 available. ie. if someone in china accesses a page originally written in french with no other translations available it will display in french. If an english translation is available it will display in english. If there is a chinese translation available it will display in chinese. 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 us know. Michael Wheatland -- Unsubscribe instructions: E-mail to website+h...@libreoffice.org List archive: http://www.libreoffice.org/lists/website/ *** All posts to this list are publicly archived for eternity ***
Re: [libreoffice-website] Re: Update on Drupal Website Progress
Hi, Le 2010-11-22 21:10, Michael Wheatland a écrit : Thanks all for the input to this concept. I just wanted to clarify a couple of points: 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 translation. 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 available. 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. 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 not cloned. 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. If there is a chinese translation available it will display in chinese. Really irrelevant. 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 us know. Again, the QA team are used to work together, so don't put constraints where they are not needed. Currently, all this has my absolute veto. Kind regards Sophie --- Founding member of The Document Foundation -- Unsubscribe instructions: E-mail to website+h...@libreoffice.org List archive: http://www.libreoffice.org/lists/website/ *** All posts to this list are publicly archived for eternity ***
Re: [libreoffice-website] Re: Update on Drupal Website Progress
WOW, this is a big reply. Sorry. Sophie, I think you may be misinterpreting most if not all of my comments. On Wed, Nov 24, 2010 at 4:46 PM, Sophie Gautier wrote: >> 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 > translation. 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 this? >>> 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 >>> available. > > 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. The layout and structure of the Drupal site remains constant across languages, but language specific content can be added to individual pages if required. 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? 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. 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 > not cloned. >>> 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. > If there >>> >>> is a chinese translation available it will display in chinese. > > Really irrelevant. It means that there is a fall back for the fall back. It means people will never get a 404 error instead of content. 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) >>> 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 >>> us know. > > 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. Not sure what constraints you were referring to, but we have not finished
Re: [libreoffice-website] Re: Update on Drupal Website Progress
Hi Michael, Michael Wheatland wrote (24-11-10 09:46) 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 know exactly how I heave to read this. But it is very likely that the various native languages will have different pages. Regards, Cor -- - giving openoffice.org its foundation :: The Document Foundation - -- Unsubscribe instructions: E-mail to website+h...@libreoffice.org List archive: http://www.libreoffice.org/lists/website/ *** All posts to this list are publicly archived for eternity ***
Re: [libreoffice-website] Re: Update on Drupal Website Progress
Cor Nouws wrote (24-11-10 10:50) Hi Michael, Michael Wheatland wrote (24-11-10 09:46) 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 know exactly how I heave to read this. But it is very likely that the various native languages will have different pages. And then I have to be clear myself too ;-) so ... different pages not only in the sense of different content, but also the naming of pages will be different. Regards, Cor -- - giving openoffice.org its foundation :: The Document Foundation - -- Unsubscribe instructions: E-mail to website+h...@libreoffice.org List archive: http://www.libreoffice.org/lists/website/ *** All posts to this list are publicly archived for eternity ***
Re: [libreoffice-website] Re: Update on Drupal Website Progress
On Wed, Nov 24, 2010 at 7:27 PM, Cor Nouws wrote: > And then I have to be clear myself too ;-) so ... > different pages not only in the sense of different content, but also the > naming of pages will be different. > >> >> Regards, >> Cor By 'Native Languages' if you mean the native language teams then yes, the site created in the subset of the community will be able to be structured in any way they want and all in their native language. If by 'Native Languages' you mean the main website ie. LibreOffice.org in french, they will have a native language interface, native language URLs, native language page naming (titles) and native language content, but the essential structure of the site will remain constant across all languages as has been established around a month ago. for example in each language there is a download page, product information pages for each application, extensions and templates directory (the actual extensions and templates being common across languages so as to avoid language bias) etc. It is encouraged that the message, meaning and layout of each page is not massively changed from an agreed template (these have not yet been developed as we are only looking at infrastructure at the moment, but this will involve extensive consultation with all native language groups). This concept will ensure that a good idea or concept implemented in one language benefits all languages in the community, with the aim to create a truly international community which is united under one common goal: "The best possible office suite across all languages". >I don't know exactly how I heave to read this. >But it is very likely that the various native languages will have different >pages. I didn't mean in their native language groups (subsection of the main site). See above. The Drupal infrastructure enforces a consistent structure on the main site, this is not an opinion. In contrast to what some opinions might be, the Drupal development team is made up of a wide variety of people having a wide variety of native languages whom along with many others (listen to the marketing conference calls) have formed a consensus that common structure for the main site (not in native language groups) is the best way to unite the community and to ensure each language is equal. This common structure is under intense development now with consultation with each segment of the community. If you wish to get involved please have a look on The Documentation Foundation Wiki. -- Unsubscribe instructions: E-mail to website+h...@libreoffice.org List archive: http://www.libreoffice.org/lists/website/ *** All posts to this list are publicly archived for eternity ***
Re: [libreoffice-website] Re: Update on Drupal Website Progress
On Wed, 24 Nov 2010 01:16:12 -0600, Sophie Gautier wrote: Hi, Le 2010-11-22 21:10, Michael Wheatland a écrit : Thanks all for the input to this concept. I just wanted to clarify a couple of points: 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 translation. 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 available. 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. 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 not cloned. 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. If there is a chinese translation available it will display in chinese. Really irrelevant. 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 us know. Again, the QA team are used to work together, so don't put constraints where they are not needed. Currently, all this has my absolute veto. Kind regards Sophie --- Founding member of The Document Foundation Sorry I am just chippin in with no background on the conversation aside from the content of this email and the title. Sophie, perhaps you want to add how would it work best instead of just saying is not good. Also from your comments it seems we should just have separate vhosts for each Language. That way it will be completely separate. I actually have been asking for this since forever, of course the best way was just going ahead and doing it ourselves instead of trying to convince an admin. But having VPS where we can generate our own site using our preferred language and technology was a solution for many of our needs that we had in the past. Of course this is taking it a bit to the extreme. But I wonder what would be the argument for not doing this. I can think of a nightmare to admin +/-72 different VPS but I also can see the benefit of having our own selection of technologies to use. -- Alexandro Colorado OOoES A.C - http://oooes.org GPG: 68D072E6 -- Unsubscribe instructions: E-mail to website+h...@libreoffice.org List archive: http://www.libreoffice.org/lists/website/ *** All posts to this list are publicly archived for eternity ***
Re: [libreoffice-website] Re: Update on Drupal Website Progress
On Wed, Nov 24, 2010 at 8:01 PM, Alexandro Colorado wrote: > Sorry I am just chippin in with no background on the conversation aside from > the content of this email and the title. Sophie, perhaps you want to add how > would it work best instead of just saying is not good. Also from your > comments it seems we should just have separate vhosts for each Language. > That way it will be completely separate. If native language teams wish to functionally separate from the community there is nothing stopping that. As can be seen with the BrOffice branding. Functional separation will however result in an overall poorer experience for that local community. The current advice from the steering committee is to create one unified site so everyone can benefit from others contributions no matter what language. > I actually have been asking for this since forever, of course the best way > was just going ahead and doing it ourselves instead of trying to convince an > admin. But having VPS where we can generate our own site using our preferred > language and technology was a solution for many of our needs that we had in > the past. Of course this is taking it a bit to the extreme. But I wonder > what would be the argument for not doing this. I can think of a nightmare to > admin +/-72 different VPS but I also can see the benefit of having our own > selection of technologies to use. Admin of VPS has become very easy with version control systems. Very simple to update all at once. I am sure this *would* be possible if the steering committee decided to change their advice, but should we be going this way? The real benefits of inclusion into one community is pooled resources independent of language, multiculturalism resulting in a better office product for all languages and best of all inclusion into conversation and discussion for people who's language does not have a large support base and cannot speak a language that does have a large support base. I would be more than interested to hear logical reasons to go in a different direction. Michael Wheatland -- Unsubscribe instructions: E-mail to website+h...@libreoffice.org List archive: http://www.libreoffice.org/lists/website/ *** All posts to this list are publicly archived for eternity ***
Re: [libreoffice-website] Re: Update on Drupal Website Progress
Hi Michael, On 24/11/2010 11:46, Michael Wheatland wrote: WOW, this is a big reply. Sorry. Sophie, I think you may be misinterpreting most if not all of my comments. On Wed, Nov 24, 2010 at 4:46 PM, Sophie Gautier wrote: 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 translation. 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 this? 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 available. 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. 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. 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 stop
Re: [libreoffice-website] Re: Update on Drupal Website Progress
I didn't want to add to the huge mail already. I still think something here is lost in translation, or maybe the drupal terminology. Drupal is not about taking away control of pages from native language teams! It is about bringing everyone together under one roof. We are not suggesting each page for all languages has to be exactly the same down to each sentence or paragraph or image. The idea is that a common framework contributed to and agreed by all stakeholders will enrich all languages on the site as is the concept with the LibreOffice software. It will also allow easier entry for people in minority languages to get more involved and create a local language version of the main LibreOffice website very easily (One thing that is largely missing at the moment in Silverstripe). The actual words on the interface such as "Why" as you referred can Easily be translated into locally relevant terms. For example it would not be translated to "Pourquoi", it might be translated to "Caractéristiques" or "Vaut-il mieux" (Sorry, I am sure they are bad examples). To give a better example the manually translated download page might be at fr.libreoffice.org/Telecharger the title would not be 'Download' it might be "telechargement-de-libreoffice", it's up to you .The point is that while the framework stays the same URLs, Titles, Headings, Content, Layout, Menu names, Links etc. can be changed to suit your language. Please do not take "framework" to mean literal translation of terms. What I mean by structure or framework is this: Landing page -Somewhere to download LibreOffice -Somewhere to download LibreOffice for Windows -Somewhere to download LibreOffice for Mac -Somewhere to download LibreOffice for Linux. -Somewhere to find out about LibreOffice Features -Somwwhere to Get support for LibreOffice -Somewhere to join the LibreOffice Community -Somewhere to get news about LibreOffice -etc. (Note I am being very non-specific, because everything else can be localised including URLS, terminology, page content, EVERYTHING ELSE) To give an Extreme example, the Brazilian team may choose to label everything BrOffice, this will still function as expected under this common framework, but even the term most fundamental to the LibreOffice project can be changed to suit local teams requirements. Having a separate local group website seperate from the main one is not prohibited, in fact it is encouraged (I have already registered libreofficeaustralia.org). For the main site the Steering Committee has directed us towards Drupal which provides this type of multicultural integration and relevant internationalisation very well on one infrastructure. Any resources on Drupal (templates, extensions, designs) can also be localised and translated if required. Also having a common pool of untranslated resources (whether they are automatically translatable or not) allows people in minority languages access to resources they would not normally get with a small local user base, which they can translate and resubmit if they wish to. This type of infrastructure would be very difficult to setup on another CMS like silverstripe. Local Team site and communications: I fully support local teams and development inside that community, I believe it would be good for transparency, efficiency and collaboration if people could peek inside and on rare occasion contribute. Do you disagree? To conclude, I have been to the French version of the Silverstripe site and it currently does not differ in "framework" from any other language (Not to get mixed up with literally translated phrases, but the underlying meaning of individual parts of the site). Are there plans to modify this site away from the underlying framework that currently exists, and if there are plans would the changes also benefit other language groups if implemented there? = This is what Drupal is about. Please let me know if I am not being crystal clear about anything. I value your concern as I understand that in the past not speaking English was like being a second class web citizen, but rest assured the plan is to embrace equality. Michael Wheatland -- Unsubscribe instructions: E-mail to website+h...@libreoffice.org List archive: http://www.libreoffice.org/lists/website/ *** All posts to this list are publicly archived for eternity ***
Re: [libreoffice-website] Re: Update on Drupal Website Progress
Can I read it short: there is a common framework for all languages and native language groups can both - change content of those pages (if they like) and - add other pages too (if they like)? Thanks, Cor Michael Wheatland wrote (24-11-10 13:49) I didn't want to add to the huge mail already. I still think something here is lost in translation, or maybe the drupal terminology. Drupal is not about taking away control of pages from native language teams! It is about bringing everyone together under one roof. We are not suggesting each page for all languages has to be exactly the same down to each sentence or paragraph or image. The idea is that a common framework contributed to and agreed by all stakeholders will enrich all languages on the site as is the concept with the LibreOffice software. It will also allow easier entry for people in minority languages to get more involved and create a local language version of the main LibreOffice website very easily (One thing that is largely missing at the moment in Silverstripe). The actual words on the interface such as "Why" as you referred can Easily be translated into locally relevant terms. For example it would not be translated to "Pourquoi", it might be translated to "Caractéristiques" or "Vaut-il mieux" (Sorry, I am sure they are bad examples). To give a better example the manually translated download page might be at fr.libreoffice.org/Telecharger the title would not be 'Download' it might be "telechargement-de-libreoffice", it's up to you .The point is that while the framework stays the same URLs, Titles, Headings, Content, Layout, Menu names, Links etc. can be changed to suit your language. Please do not take "framework" to mean literal translation of terms. What I mean by structure or framework is this: Landing page -Somewhere to download LibreOffice -Somewhere to download LibreOffice for Windows -Somewhere to download LibreOffice for Mac -Somewhere to download LibreOffice for Linux. -Somewhere to find out about LibreOffice Features -Somwwhere to Get support for LibreOffice -Somewhere to join the LibreOffice Community -Somewhere to get news about LibreOffice -etc. (Note I am being very non-specific, because everything else can be localised including URLS, terminology, page content, EVERYTHING ELSE) To give an Extreme example, the Brazilian team may choose to label everything BrOffice, this will still function as expected under this common framework, but even the term most fundamental to the LibreOffice project can be changed to suit local teams requirements. Having a separate local group website seperate from the main one is not prohibited, in fact it is encouraged (I have already registered libreofficeaustralia.org). For the main site the Steering Committee has directed us towards Drupal which provides this type of multicultural integration and relevant internationalisation very well on one infrastructure. Any resources on Drupal (templates, extensions, designs) can also be localised and translated if required. Also having a common pool of untranslated resources (whether they are automatically translatable or not) allows people in minority languages access to resources they would not normally get with a small local user base, which they can translate and resubmit if they wish to. This type of infrastructure would be very difficult to setup on another CMS like silverstripe. Local Team site and communications: I fully support local teams and development inside that community, I believe it would be good for transparency, efficiency and collaboration if people could peek inside and on rare occasion contribute. Do you disagree? To conclude, I have been to the French version of the Silverstripe site and it currently does not differ in "framework" from any other language (Not to get mixed up with literally translated phrases, but the underlying meaning of individual parts of the site). Are there plans to modify this site away from the underlying framework that currently exists, and if there are plans would the changes also benefit other language groups if implemented there? = This is what Drupal is about. Please let me know if I am not being crystal clear about anything. I value your concern as I understand that in the past not speaking English was like being a second class web citizen, but rest assured the plan is to embrace equality. Michael Wheatland -- - giving openoffice.org its foundation :: The Document Foundation - -- Unsubscribe instructions: E-mail to website+h...@libreoffice.org List archive: http://www.libreoffice.org/lists/website/ *** All posts to this list are publicly archived for eternity ***
