Re: [libreoffice-website] Request to modify MediaWiki:Geshi.css
Hi Florian, On 24/11/2010 22:23, Florian Effenberger wrote: Hi Sophie, Sophie Gautier wrote on 2010-11-24 12.32: Could one of the wiki admin modify the MediaWiki:Geshi.css in that way : Thanks a lot! Kind regards Sophie -- 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: Proposed Drupal Frontpage and Genral pages theme -- Drupal Web. Dev. Team
Hi Carlos! Am Dienstag, den 23.11.2010, 22:36 -0600 schrieb Carlos Jenkins: > 2010/11/23 Ivan M. > > > Just a quick note regarding analytics - I'd heartily recommend Piwik [...] > +1 :D > > I'll document this in the Drupal wiki pages later. Great, thanks a lot!!! Bye, Christoph -- 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 ***
[libreoffice-website] Re: Proposed Drupal Frontpage and Genral pages theme -- Drupal Web. Dev. Team
Le 2010-11-24 13:51, Christian Lohmaier a écrit : Hi Marc, On Wed, Nov 24, 2010 at 6:35 PM, Marc Paré wrote: Thanks. I have registered as " marcpare " And you're added (login via http[s]://test.libreoffice.org/admin ) ciao Christian Thanks Christian Marc -- 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] Request to modify MediaWiki:Geshi.css
Hi Sophie, Sophie Gautier wrote on 2010-11-24 12.32: Could one of the wiki admin modify the MediaWiki:Geshi.css in that way : done. Florian -- Florian Effenberger Steering Committee and Founding Member of The Document Foundation Tel: +49 8341 99660880 | Mobile: +49 151 14424108 Skype: floeff | Twitter/Identi.ca: @floeff -- 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] name for the mailing list archives
Hi Bernhard, Florian, *, Bernhard Dippold schrieb: >ml_archives.tdf or ml.archives.tdf ? >This would allow other archives to be structured similarly: >libo_archives.tdf or libo.archives.tdf >wiki_archives.tdf or wiki.archives.tdf >iso_archives.tdf or iso.archives.tdf >only depending on what we want to be archived (even another software >under the TDF umbrella would be possible: sw-name.archives.tdf) That's my favorite too. sub.archives.tdf gives the possibility to have a full featured archives.tdf for detailed browsing the several archives even if for reason of space located on another/different machine(s). Btw. There is a simple .htaccess trick to keep /lists on the CMS host. Only drawback: CMS site "lists" must not exist or won't work if so. I realized that on http://devel.libreofficebox.org/static/ Gruß/regards -- Friedrich Libreoffice-Box http://libreofficebox.org/ LibreOffice and more on CD/DVD images (german version already started) -- 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] Update on Drupal Website Progress
Hi Bernhard, Am 24.11.2010 19:43, schrieb Bernhard Dippold: > http://www.libreoffice.org/ > > and it's pages like [...] > All these pages are mainly created in English, but can be translated > to any other language - keeping the structure and content of the pages. [...] > For any native language team the content of their language based > sub-site (for French http://fr.libreoffice.org, German > http://de.libreoffice.org and so on) will be created by themselves > and might be totally different from the content of any other native > lang page. Additionally, there can be special links from the NL site to translated pages in the main site. For example: The page http://www.test.libreoffice.org/download/ on the main site has a german translation inside the main site. When you browse http://www.de.test.libreoffice.org you can click on "Download" which actually leads you to the translated page inside the main page. However it appears to the user as if the german download page was inside the german NL site. Gruß Stefan -- LibreOffice - Die Freiheit nehm' ich mir! -- 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: Proposed Drupal Frontpage and Genral pages theme -- Drupal Web. Dev. Team
Hi Marc, On Wed, Nov 24, 2010 at 6:35 PM, Marc Paré wrote: > > Thanks. I have registered as " marcpare " And you're added (login via http[s]://test.libreoffice.org/admin ) ciao Christian -- 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] Update on Drupal Website Progress
Hi Sophie, all, I think there are still some misunderstandings in what Michael and the Drupal team are developing. I hope I can solve this by giving some examples. Please correct me if I'm the one misunderstanding the context... Sophie Gautier schrieb: Hi Michael, all, I'm sorry, I'm currently travelling and really very partially connected, but there is a point where I would like to give clarification: [...] (-) All languages will have the same content, some of which will be automatically translated so collaboration can occur across languages. (Forums, News, Extensions, Templates) Michael speaks here of the main site http://www.libreoffice.org/ and it's pages like http://www.libreoffice.org/about.html http://www.libreoffice.org/why.html and so on. Some international resources will be covered too: http://forum.libreoffice.org/ http://templates.libreoffice.org/ and the like. All these pages are mainly created in English, but can be translated to any other language - keeping the structure and content of the pages. Of course manual translation produces better results, but if there is no translation existent, the page stays in English. It might be translated to the language in question by a "google translate button" or something similar, but all of this stays on the main site. I assume that the website will present the main site in the language detected from the browser that can be modified manually. You do not mean that the sites in different languages will look the same with the same content? Only for the main site http://www.libreoffice.org Language projects need to have their own content and do not rely on automatic translation because it deliver very poor quality. For any native language team the content of their language based sub-site (for French http://fr.libreoffice.org, German http://de.libreoffice.org and so on) will be created by themselves and might be totally different from the content of any other native lang page. It's up to the team if a page like http://fr.libreoffice.org/why.html would look like http://www.libreoffice.org/why.html if looked at it with a French browser (or modified standard language). [...]But for the content, really each project should be able to manage it's own content. It stays independent - only the main page will get a translation that has not been possible at the main OOo page. Does this sound reasonable? I hope I got it right - if not, please correct me! Best regards Bernhard PS: To establish a consistent LibreOffice branding I'd really like to see common visuals and structures shared among all the different sub-sites of www.libreoffice.org. Therefore it is crucial to include all the feedback by the different language teams in the decision on how this visual identity design should look like. But that's another story - to be told on des...@libreoffice.org... -- 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 ***
[libreoffice-website] Re: Proposed Drupal Frontpage and Genral pages theme -- Drupal Web. Dev. Team
Le 2010-11-24 12:22, Christian Lohmaier a écrit : Hi Marc, *, On Wed, Nov 24, 2010 at 6:15 PM, Marc Paré wrote: Le 2010-11-24 11:11, Christian Lohmaier a écrit : On Tue, Nov 23, 2010 at 10:27 PM, Marc Paréwrote: Le 2010-11-23 15:38, Michael Wheatland a écrit : let me know if you need anymore help. I will help out too. :-) Help is always needed, and you're more than welcome to help out :-) I'll check in with Michael and see where if he needs help with this. He is considerably quicker with this than I am. Can you also give me authority to publish as well to save some time. Sure - but you need to create an account first https://test.libreoffice.org/ForumMemberProfile/register ciao Christian Thanks. I have registered as " marcpare " Cheers Marc -- 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: Proposed Drupal Frontpage and Genral pages theme -- Drupal Web. Dev. Team
Hi Marc, *, On Wed, Nov 24, 2010 at 6:15 PM, Marc Paré wrote: > Le 2010-11-24 11:11, Christian Lohmaier a écrit : >> On Tue, Nov 23, 2010 at 10:27 PM, Marc Paré wrote: >>> Le 2010-11-23 15:38, Michael Wheatland a écrit : >>> >>> let me know if you need anymore help. I will help out too. :-) >> >> Help is always needed, and you're more than welcome to help out :-) > > I'll check in with Michael and see where if he needs help with this. He is > considerably quicker with this than I am. Can you also give me authority to > publish as well to save some time. Sure - but you need to create an account first https://test.libreoffice.org/ForumMemberProfile/register ciao Christian -- 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 ***
[libreoffice-website] Re: Proposed Drupal Frontpage and Genral pages theme -- Drupal Web. Dev. Team
Le 2010-11-24 11:11, Christian Lohmaier a écrit : Hi Marc, *, On Tue, Nov 23, 2010 at 10:27 PM, Marc Paré wrote: Le 2010-11-23 15:38, Michael Wheatland a écrit : let me know if you need anymore help. I will help out too. :-) Help is always needed, and you're more than welcome to help out :-) ciao Christian I'll check in with Michael and see where if he needs help with this. He is considerably quicker with this than I am. Can you also give me authority to publish as well to save some time. Cheers Marc -- 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] Proposed Drupal Frontpage and Genral pages theme -- Drupal Web. Dev. Team
Hi Alexandro, *, On Wed, Nov 24, 2010 at 1:52 PM, Michael Wheatland wrote: > On Wed, Nov 24, 2010 at 8:53 PM, Alexandro Colorado > wrote: >> ok thanks for the info. However I still wonder how adaptive is this theme, >> does it uses % and adaptive rules? > > This question is less about the theme and more about the underlying > infrastructure. No, it is a property of the theme, as the underlying infrastructure just produces html, and how that html then looks is up the the css. It is the job of the CMS, be it Drupal or Silverstripe to produce html that can be turned into whatever the designer wants it to be. (I know silverstripe is flexible enough here, and I'd be surprised if drupal couldn't be convinced into outputting whatever is neede as well). The hard thing is when you need to bias style/visual appearance against "works on every possible screen size". But that is no limitation of the CMS, but the css/styling itself. you cannot just shrink everything for a smaller screensize for example. The more eye-candy you add, the more difficult it gets of course. ciao Christian -- 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: Proposed Drupal Frontpage and Genral pages theme -- Drupal Web. Dev. Team
Hi Marc, *, On Tue, Nov 23, 2010 at 10:27 PM, Marc Paré wrote: > Le 2010-11-23 15:38, Michael Wheatland a écrit : > > let me know if you need anymore help. I will help out too. :-) Help is always needed, and you're more than welcome to help out :-) ciao Christian -- 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] Proposed Drupal Frontpage and Genral pages theme -- Drupal Web. Dev. Team
Hi * On Tue, Nov 23, 2010 at 9:38 PM, Michael Wheatland wrote: > On Wed, Nov 24, 2010 at 1:20 AM, Christian Lohmaier > wrote >> So no matter whether you work on drupal or not, please also think >> about the present, not only about the future. > > I have signed up under the name Wheatbix. Can you give me authority on > the site to publish Thanks for also posting in a seperate thread and sorry for the delay. > Can you also point me towards instructions on how to work silverstripe > and if there is any planning regarding the content. It is pretty straightforward. After you login to the system, you're presented with a site-tree hierarchy. http://frupic.frubar.net/16822 to create a new page, select the page that the new page should be a child of and use the "create page" button. From the list of available page-types choose "Page" for a regular page and click add. Then start adding the title and content to the editor-area. Use the buttons at the bottom to save / request publication / save and publish. On the behaviour tab you can select whether it should be listed in the menu and change the pagetype for an existing page to another one, in case it is needed. To rearrange pages, enable the "use drag and drop to reorganize" function in the site-tree area and use drag and drop to move the page in the hierarchy. To upload files/images, go to the Files & Images section. Again it should be pretty straightforward - there is a folder-hierarchy with the ability to create new folders, and the folder's themselves have an "upload" tab where you can upload files from your disk. in case of any questions, don't hesitate to ask. ciao Christian -- 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 ***
[libreoffice-website] Re: Update on Drupal Website Progress
Le 2010-11-24 05:56, Michael Wheatland a écrit : I think we could call this a problem in communication. Let's reduce it in as simple terms as possible: * Drupal offers native language site control. * Drupal offers a common framework for all native language groups (changes are possible depending on the native language sites' needs) * Drupal offers instant translation for site visitors The "instant translation" will NOT create pages; will NOT add pages to other native language sites. The "instant translation" tools will enable users of other native languages, the ability to surf and browse other native language sites, forums, mailists in their own language. These tools are in the hope of opening all sites to all visitors regardless of language barriers. The "instant translation" tools are only to facilitate a user's ability to browse/surf to other native language parts of the LibreOffice.org site. This is what is proposed. Marc -- 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] SilverStripe English Editor
Hi Michael, On Wed, Nov 24, 2010 at 10:43 AM, Michael Wheatland wrote: > I have signed up for Silverstripe under the username Wheatbix. > Can you please provide write privileges. You're added - login to the cms via https://test.libreoffice.org/admin ciao Christian -- 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 ***
Re: [libreoffice-website] printing the website
Hi Florian, *,
On Wed, Nov 24, 2010 at 10:06 AM, Florian Effenberger
wrote:
> Christian Lohmaier wrote on 2010-11-23 14.58:
>> [...]
> thanks for investigating! Can this easily be done?
debugging print style css is kind of annoying task - but I added some
rules that should render it better now. I removed the links from the
header area (also from the navigation tabs), and don't force their
size to 100px, so that they have a chance to fit on one single line,
also tweaked other stuff like margins/padding to make it render a
little more space-efficiently.
I added these statements:
div#header a:after {
content: "";
}
ul#nav {
font-size: 80%;
float: right;
width: 100%;
min-width: 0;
}
ul#nav li a {
width: auto;
height: auto;
margin-left: 1em;
}
div#container {
width: 100%;
}
div#container > h2:first-child {
margin-top: 0.6em;
padding-top: 0;
}
> Interestingly, from time to time, when connecting through UMTS, I see the
> same page error...
Then that browser for some reason prefers to render the page with the
"print" output selection, rather than the default "screen" type...
ciao
Christian
--
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] Proposed Drupal Frontpage and Genral pages theme -- Drupal Web. Dev. Team
On Wed, Nov 24, 2010 at 8:53 PM, Alexandro Colorado wrote: > ok thanks for the info. However I still wonder how adaptive is this theme, > does it uses % and adaptive rules? This question is less about the theme and more about the underlying infrastructure. Drupal can do almost anything. For this example see: http://drupal.org/project/textsize Modules (extensions) are the powerhouse of the drupal system. There are currently 6958 different modules available. I hate to say it but "There's an app for that" :) 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
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 ***
[libreoffice-website] Request to modify MediaWiki:Geshi.css
Hi dear wiki admins,
Could one of the wiki admin modify the MediaWiki:Geshi.css in that way :
div.mw-geshi {
padding: 1em;
margin: 1em 0;
border: 1px dashed #2f6fab;
}
Thanks in advance
Kind regards
Sophie
--
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] Proposed Drupal Frontpage and Genral pages theme -- Drupal Web. Dev. Team
On Wed, 24 Nov 2010 05:01:19 -0600, Michael Wheatland wrote: Which tools are you using for CSS, are you using the Blueprint CSS framework like the original TDF site? The CSS framework will be based off the 'Genesis' Drupal base theme then modified to match the design when finalised as has been discussed here before. There are a lot of core drupal functionality in both the front and back end which requires adherence to a specific CSS structure for the common elements. http://drupal.org/project/genesis Michael Wheatland ok thanks for the info. However I still wonder how adaptive is this theme, does it uses % and adaptive rules? -- Alexandro Colorado -- 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] Proposed Drupal Frontpage and Genral pages theme -- Drupal Web. Dev. Team
> Which tools are you using for CSS, are you using the Blueprint CSS framework > like the original TDF site? The CSS framework will be based off the 'Genesis' Drupal base theme then modified to match the design when finalised as has been discussed here before. There are a lot of core drupal functionality in both the front and back end which requires adherence to a specific CSS structure for the common elements. http://drupal.org/project/genesis 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
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] Proposed Drupal Frontpage and Genral pages theme -- Drupal Web. Dev. Team
On Wed, 24 Nov 2010 01:37:15 -0600, Carlos Jenkins wrote: 2010/11/24 klaus-jürgen weghorn ol Hi Marc, Am 23.11.2010 12:57, schrieb Marc Paré: http://wiki.documentfoundation.org/File:DrupalFrontpage120.png What will I see first on a display with 1024x768 pixel The same, but almost without the gray borders. or less than that? A horizontal scroll bar. Think of all the projectors, netbooks and tablets, presentations on fairs. Is the website then usable and readable? This is expected to be a fluid layout, shrinks to 1024px wide and grows up to 1280px wide (because of line width before break readability issues). This is acceptable for you? We can think also of a portable devices/small screen portal with much less prettiness. Kind regards General rule is preffered to have % on the css and some other type of styling tool to increase/decrease fonts. Of course that many desktop browsers already have that feature and even the mobile ones have some type of zooming tool. Which tools are you using for CSS, are you using the Blueprint CSS framework like the original TDF site? -- 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, 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 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
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
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 ***
[libreoffice-website] SilverStripe English Editor
I have signed up for Silverstripe under the username Wheatbix. Can you please provide write privileges. Thanks, 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] printing the website
2010.11.24 11:18, Rimas Kudelis rašė:
2010.11.24 11:06, Florian Effenberger rašė:
Hi Christian,
Christian Lohmaier wrote on 2010-11-23 14.58:
/css/blueprint/print.css →
a:link:after, a:visited:after {
content: " (" attr(href) ") ";
font-size: 90%;
}
should either be disabled for div#header div#tagline a (or h1 a) or it
should add some spacing element as well to push the navbar further
down.
thanks for investigating! Can this easily be done?
Interestingly, from time to time, when connecting through UMTS, I see
the same page error...
Why not just add this:
ul#nav {
display: none;
}
to the print stylesheet? It doesn't make much sense to have the menu
printed there anyway.
Hm, I obviously didn't read what Christian said. My suggestion adds to,
and not replaces his.
Rimas
--
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] printing the website
2010.11.24 11:06, Florian Effenberger rašė:
Hi Christian,
Christian Lohmaier wrote on 2010-11-23 14.58:
/css/blueprint/print.css →
a:link:after, a:visited:after {
content: " (" attr(href) ") ";
font-size: 90%;
}
should either be disabled for div#header div#tagline a (or h1 a) or it
should add some spacing element as well to push the navbar further
down.
thanks for investigating! Can this easily be done?
Interestingly, from time to time, when connecting through UMTS, I see
the same page error...
Why not just add this:
ul#nav {
display: none;
}
to the print stylesheet? It doesn't make much sense to have the menu
printed there anyway.
Rimas
--
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] printing the website
Hi Christian,
Christian Lohmaier wrote on 2010-11-23 14.58:
/css/blueprint/print.css →
a:link:after, a:visited:after {
content: " (" attr(href) ") ";
font-size: 90%;
}
should either be disabled for div#header div#tagline a (or h1 a) or it
should add some spacing element as well to push the navbar further
down.
thanks for investigating! Can this easily be done?
Interestingly, from time to time, when connecting through UMTS, I see
the same page error...
Florian
--
Florian Effenberger
Steering Committee and Founding Member of The Document Foundation
Tel: +49 8341 99660880 | Mobile: +49 151 14424108
Skype: floeff | Twitter/Identi.ca: @floeff
--
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] printing the website
On Tue, Nov 23, 2010 at 11:06 PM, Florian Effenberger wrote: > Hi, > > I just wanted to print out http://www.documentfoundation.org/contact/ > At least using Firefox, the tabs on the top of the page look really > strange... can someone confirm? > > Thanks, > Florian If you wish to print a verbatim copy of the website I suggest you use a 'screen/whole website capture' tool such as Screen Capture for the Chromium project or similar. See https://chrome.google.com/extensions/detail/cpngackimfmofbokmjmljamhdncknpmg?hl=en I am sure there is something similar for Firefox, I think it is called Piknik? 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
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
