Re: Brainstorming: Can we refactor the website to make translation easier?
On Fri, Aug 23, 2013 at 5:12 PM, janI j...@apache.org wrote: On 23 August 2013 21:11, Rob Weir robw...@apache.org wrote: On Fri, Aug 23, 2013 at 12:21 PM, janI j...@apache.org wrote: On 23 August 2013 17:58, Rob Weir robw...@apache.org wrote: (Responses to dev@openoffice.apache.org, please) Obviously our website is quite large. Google reports 21207 pages indexed in the www subdomain, and a further 48075 pages in the wiki subdomain. But for purpose of this post, when I talk about the home page I'm talking about the contents of our main index.html and the most commonly visited pages directly linked to it, e.g., the why/download/product/get-involved, etc. pages. This core homepage content amounts to around 25 pages. Today this content is scattered around the content tree. Some of it is in the root. Some of it in /why and /download directories. Some of it is template-related and is in /templates rather than in /content. As a test I tried to create my own NL page, in the fictitious xx locale. You can see it here: http://www.openoffice.org/xx/ It is not working correctly, but it already required a lot of non-trivial hacking: 1) I had to hunt around and guess which files to copy. Do I copy scripts, images and CSS, or just content pages? Some of the directories had out-dated content that was not linked to my anyone. It was hard to figure out what the minimum amount of content needed was, and where it was located. 2) The main index.html file had to be edited to refer to CSS in the root, rather than current directory 3) Download page is missed up, missing CSS and/or scripts. Presumably I need to copy something into the xx/download dir, or edit scripts to make them refer /download off the root. 4) The /xx/why pages are not showing the right side navigation now. I must have missed something there as well. Of course, I could figure the above out eventually. It just requires some time and effort and trial and error. But none of this is documented, and even if it were this is a fragile approach and probably beyond th web development skills of a typical translator. But we do know this has been done for some languages. They got it to work. The German page is a good example: http://www.openoffice.org/de/ Now this looks good, but it is still a messy thing from a maintenance perspective. If we make structural changes to the main English page, then those changes need to be manually merged into to every NL page. What can we do to improve this? Here's my idea: 1) What if we refactored the home page so it was all self-contained into these directories: /scripts, /styles, /images and /en/? 2) Make the /en directory be pure content. Only the stuff that needs to be translated. It loads everything else, scripts, images, etc., via URLs relative to the root, e.g.., in /scripts, /styles, etc. 3) Reduce or eliminate any embedded Javascript within pages. For example, refactor the code in download/index.html so it is external and depends on JSON resource files for translated strings. Aim so translators never need to touch script. 4) Ultimate goal is for someone to be able to jump start a new NL home page by simply requesting an svn copy of the /en directory, and then editing the resulting files. No one should ever need to do what I'm doing with the xx pages. 5) Maintenance is far easier. Most things like changing the scripts, is done in one place only. But even changes to the HTML are easier. Since we then have a common branch point via the svn copy, when structural changes are added to the main /en HTML, these can be merged in more elegantly to the translated versions, using Subversion. 6) Via Apache redirects we can ensure that the default call to www.openoffice.org/ goes to /en/. Conceivably we could also do locale detection and send requests automatically to the appropriate NL home page. A variation on the above would be to use Pootle, rather than svn copy/merge to maintain the translations. But that would require the same refactoring work to enable it. And it would require further investigation to identify a way of extracting and merging translation strings in MDText files as well as (X)HTML files. This is obviously more than a one-person task. So I'd be interested in hearing what you think in general about this approach, whether there is a simpler alternative I've missed, and whether this is something you'd be interested in helping with. I like a lot of your ideas, let me add my own experience. Thanks. If the our pages do not contain text, but that is totally outsourced in one or more json objects, then translation becomes easy, and the pages themself stay simple. when the url is called without arguments the en-json is used, and if called with lang=xx xx-json is used. I like the idea
Re: Brainstorming: Can we refactor the website to make translation easier?
Since some of us like me are on vacation would it possible to either put this into a cwiki page or other clear summary. I have a lot I can add about the current setup like why you lost the rightnav - ie you need a subdirectory in templates. Regards, Dave Sent from my iPhone On Aug 26, 2013, at 8:45 AM, Rob Weir robw...@apache.org wrote: On Fri, Aug 23, 2013 at 5:12 PM, janI j...@apache.org wrote: On 23 August 2013 21:11, Rob Weir robw...@apache.org wrote: On Fri, Aug 23, 2013 at 12:21 PM, janI j...@apache.org wrote: On 23 August 2013 17:58, Rob Weir robw...@apache.org wrote: (Responses to dev@openoffice.apache.org, please) Obviously our website is quite large. Google reports 21207 pages indexed in the www subdomain, and a further 48075 pages in the wiki subdomain. But for purpose of this post, when I talk about the home page I'm talking about the contents of our main index.html and the most commonly visited pages directly linked to it, e.g., the why/download/product/get-involved, etc. pages. This core homepage content amounts to around 25 pages. Today this content is scattered around the content tree. Some of it is in the root. Some of it in /why and /download directories. Some of it is template-related and is in /templates rather than in /content. As a test I tried to create my own NL page, in the fictitious xx locale. You can see it here: http://www.openoffice.org/xx/ It is not working correctly, but it already required a lot of non-trivial hacking: 1) I had to hunt around and guess which files to copy. Do I copy scripts, images and CSS, or just content pages? Some of the directories had out-dated content that was not linked to my anyone. It was hard to figure out what the minimum amount of content needed was, and where it was located. 2) The main index.html file had to be edited to refer to CSS in the root, rather than current directory 3) Download page is missed up, missing CSS and/or scripts. Presumably I need to copy something into the xx/download dir, or edit scripts to make them refer /download off the root. 4) The /xx/why pages are not showing the right side navigation now. I must have missed something there as well. Of course, I could figure the above out eventually. It just requires some time and effort and trial and error. But none of this is documented, and even if it were this is a fragile approach and probably beyond th web development skills of a typical translator. But we do know this has been done for some languages. They got it to work. The German page is a good example: http://www.openoffice.org/de/ Now this looks good, but it is still a messy thing from a maintenance perspective. If we make structural changes to the main English page, then those changes need to be manually merged into to every NL page. What can we do to improve this? Here's my idea: 1) What if we refactored the home page so it was all self-contained into these directories: /scripts, /styles, /images and /en/? 2) Make the /en directory be pure content. Only the stuff that needs to be translated. It loads everything else, scripts, images, etc., via URLs relative to the root, e.g.., in /scripts, /styles, etc. 3) Reduce or eliminate any embedded Javascript within pages. For example, refactor the code in download/index.html so it is external and depends on JSON resource files for translated strings. Aim so translators never need to touch script. 4) Ultimate goal is for someone to be able to jump start a new NL home page by simply requesting an svn copy of the /en directory, and then editing the resulting files. No one should ever need to do what I'm doing with the xx pages. 5) Maintenance is far easier. Most things like changing the scripts, is done in one place only. But even changes to the HTML are easier. Since we then have a common branch point via the svn copy, when structural changes are added to the main /en HTML, these can be merged in more elegantly to the translated versions, using Subversion. 6) Via Apache redirects we can ensure that the default call to www.openoffice.org/ goes to /en/. Conceivably we could also do locale detection and send requests automatically to the appropriate NL home page. A variation on the above would be to use Pootle, rather than svn copy/merge to maintain the translations. But that would require the same refactoring work to enable it. And it would require further investigation to identify a way of extracting and merging translation strings in MDText files as well as (X)HTML files. This is obviously more than a one-person task. So I'd be interested in hearing what you think in general about this approach, whether there is a simpler alternative I've missed, and whether this is something you'd be interested in helping with. I like a lot of your ideas, let me add my own experience. Thanks. If the our pages do not
Re: Brainstorming: Can we refactor the website to make translation easier?
On Fri, Aug 23, 2013 at 5:29 PM, Kay Schenk kay.sch...@gmail.com wrote: On Fri, Aug 23, 2013 at 8:58 AM, Rob Weir robw...@apache.org wrote: (Responses to dev@openoffice.apache.org, please) Obviously our website is quite large. Google reports 21207 pages indexed in the www subdomain, and a further 48075 pages in the wiki subdomain. But for purpose of this post, when I talk about the home page I'm talking about the contents of our main index.html and the most commonly visited pages directly linked to it, e.g., the why/download/product/get-involved, etc. pages. This core homepage content amounts to around 25 pages. Today this content is scattered around the content tree. Some of it is in the root. Some of it in /why and /download directories. Some of it is template-related and is in /templates rather than in /content. As a test I tried to create my own NL page, in the fictitious xx locale. You can see it here: http://www.openoffice.org/xx/ It is not working correctly, but it already required a lot of non-trivial hacking: 1) I had to hunt around and guess which files to copy. Do I copy scripts, images and CSS, or just content pages? Some of the directories had out-dated content that was not linked to my anyone. It was hard to figure out what the minimum amount of content needed was, and where it was located. 2) The main index.html file had to be edited to refer to CSS in the root, rather than current directory Some of what you are experiencing re the css issues are due to many migrations and css that applies ONLY to the home page and not others. There's no reason why this should be this way really. SOme of us dealing with this on a day to day basis knew this but were afraid to mess with it. 3) Download page is missed up, missing CSS and/or scripts. Presumably I need to copy something into the xx/download dir, or edit scripts to make them refer /download off the root. 4) The /xx/why pages are not showing the right side navigation now. I must have missed something there as well. hmmm...not seeing what you've done, this could be do to some CMS setup. I think I see what is missing. I need to add: /templates/xx/why/ssi.mdtext That means that the NL homepages are not really self-contained. They are in /content/xx and also in /templates/xx. That is OK, I suppose. Of course, I could figure the above out eventually. It just requires some time and effort and trial and error. But none of this is documented, and even if it were this is a fragile approach and probably beyond th web development skills of a typical translator. But we do know this has been done for some languages. They got it to work. The German page is a good example: http://www.openoffice.org/de/ Now this looks good, but it is still a messy thing from a maintenance perspective. If we make structural changes to the main English page, then those changes need to be manually merged into to every NL page. What can we do to improve this? Here's my idea: 1) What if we refactored the home page so it was all self-contained into these directories: /scripts, /styles, /images and /en/? 2) Make the /en directory be pure content. Only the stuff that needs to be translated. It loads everything else, scripts, images, etc., via URLs relative to the root, e.g.., in /scripts, /styles, etc. 3) Reduce or eliminate any embedded Javascript within pages. I didn't think we had a lot of this but maybe more than we should. For example, refactor the code in download/index.html so it is external and depends on JSON resource files for translated strings. Aim so translators never need to touch script. Well I don't really know JSON so I can't speak to this. Will investigate. though we do/did make extensive use of JS data structures in the past. You can read about one JSON-based approach here: http://blog.mozilla.org/webdev/2011/10/06/i18njs-internationalize-your-javascript-with-a-little-help-from-json-and-the-server/ My original idea was to use such an approach only where we had language strings tightly mixed with JS, like on the download page, where we generate the boxes. It might be overkill to do this approach with normal HTML or MDText content. The nice thing about HTML is a translator has the context, they can test their work on their own machines, and we have the W3C markup validator that they can use to check the final page. So I think translators can handle that. 4) Ultimate goal is for someone to be able to jump start a new NL home page by simply requesting an svn copy of the /en directory, and then editing the resulting files. No one should ever need to do what I'm doing with the xx pages. I think once upon a time -- maybe LONG ago -- the NL pages were standardized to be clone of the main index page. But, various NL groups wanted more of their own identity, and so we have what we have. Possibly. So I guess I'm pushing for moving
Re: Brainstorming: Can we refactor the website to make translation easier?
On Mon, Aug 26, 2013 at 9:57 AM, Dave Fisher w...@apache.org wrote: Since some of us like me are on vacation would it possible to either put this into a cwiki page or other clear summary. I have a lot I can add about the current setup like why you lost the rightnav - ie you need a subdirectory in templates. Great. I was hoping that you in particular would weigh in on this, since I know you have given this a lot of thought as well. I'll continue hacking in the xx directory and start a new thread summarizing the state of the work in a couple weeks. -Rob Regards, Dave Sent from my iPhone On Aug 26, 2013, at 8:45 AM, Rob Weir robw...@apache.org wrote: On Fri, Aug 23, 2013 at 5:12 PM, janI j...@apache.org wrote: On 23 August 2013 21:11, Rob Weir robw...@apache.org wrote: On Fri, Aug 23, 2013 at 12:21 PM, janI j...@apache.org wrote: On 23 August 2013 17:58, Rob Weir robw...@apache.org wrote: (Responses to dev@openoffice.apache.org, please) Obviously our website is quite large. Google reports 21207 pages indexed in the www subdomain, and a further 48075 pages in the wiki subdomain. But for purpose of this post, when I talk about the home page I'm talking about the contents of our main index.html and the most commonly visited pages directly linked to it, e.g., the why/download/product/get-involved, etc. pages. This core homepage content amounts to around 25 pages. Today this content is scattered around the content tree. Some of it is in the root. Some of it in /why and /download directories. Some of it is template-related and is in /templates rather than in /content. As a test I tried to create my own NL page, in the fictitious xx locale. You can see it here: http://www.openoffice.org/xx/ It is not working correctly, but it already required a lot of non-trivial hacking: 1) I had to hunt around and guess which files to copy. Do I copy scripts, images and CSS, or just content pages? Some of the directories had out-dated content that was not linked to my anyone. It was hard to figure out what the minimum amount of content needed was, and where it was located. 2) The main index.html file had to be edited to refer to CSS in the root, rather than current directory 3) Download page is missed up, missing CSS and/or scripts. Presumably I need to copy something into the xx/download dir, or edit scripts to make them refer /download off the root. 4) The /xx/why pages are not showing the right side navigation now. I must have missed something there as well. Of course, I could figure the above out eventually. It just requires some time and effort and trial and error. But none of this is documented, and even if it were this is a fragile approach and probably beyond th web development skills of a typical translator. But we do know this has been done for some languages. They got it to work. The German page is a good example: http://www.openoffice.org/de/ Now this looks good, but it is still a messy thing from a maintenance perspective. If we make structural changes to the main English page, then those changes need to be manually merged into to every NL page. What can we do to improve this? Here's my idea: 1) What if we refactored the home page so it was all self-contained into these directories: /scripts, /styles, /images and /en/? 2) Make the /en directory be pure content. Only the stuff that needs to be translated. It loads everything else, scripts, images, etc., via URLs relative to the root, e.g.., in /scripts, /styles, etc. 3) Reduce or eliminate any embedded Javascript within pages. For example, refactor the code in download/index.html so it is external and depends on JSON resource files for translated strings. Aim so translators never need to touch script. 4) Ultimate goal is for someone to be able to jump start a new NL home page by simply requesting an svn copy of the /en directory, and then editing the resulting files. No one should ever need to do what I'm doing with the xx pages. 5) Maintenance is far easier. Most things like changing the scripts, is done in one place only. But even changes to the HTML are easier. Since we then have a common branch point via the svn copy, when structural changes are added to the main /en HTML, these can be merged in more elegantly to the translated versions, using Subversion. 6) Via Apache redirects we can ensure that the default call to www.openoffice.org/ goes to /en/. Conceivably we could also do locale detection and send requests automatically to the appropriate NL home page. A variation on the above would be to use Pootle, rather than svn copy/merge to maintain the translations. But that would require the same refactoring work to enable it. And it would require further investigation to identify a way of extracting and merging translation strings in MDText files as well as (X)HTML files. This is obviously more than a one-person task.
Re: Brainstorming: Can we refactor the website to make translation easier?
Sent from my iPhone On Aug 26, 2013, at 9:20 AM, Rob Weir robw...@apache.org wrote: On Mon, Aug 26, 2013 at 9:57 AM, Dave Fisher w...@apache.org wrote: Since some of us like me are on vacation would it possible to either put this into a cwiki page or other clear summary. I have a lot I can add about the current setup like why you lost the rightnav - ie you need a subdirectory in templates. Great. I was hoping that you in particular would weigh in on this, since I know you have given this a lot of thought as well. I'll continue hacking in the xx directory and start a new thread summarizing the state of the work in a couple weeks. Beautiful. If xx is checked in then I'll hack on it too and we can collaborate. I think we can also look into improving branding element standards which will need to fit in the framework. I wonder if there is an httpd module that can hold a database or lookup table of redirections? If so I need something like it for work too which gives me some cycles. Regards, Dave -Rob Regards, Dave Sent from my iPhone On Aug 26, 2013, at 8:45 AM, Rob Weir robw...@apache.org wrote: On Fri, Aug 23, 2013 at 5:12 PM, janI j...@apache.org wrote: On 23 August 2013 21:11, Rob Weir robw...@apache.org wrote: On Fri, Aug 23, 2013 at 12:21 PM, janI j...@apache.org wrote: On 23 August 2013 17:58, Rob Weir robw...@apache.org wrote: (Responses to dev@openoffice.apache.org, please) Obviously our website is quite large. Google reports 21207 pages indexed in the www subdomain, and a further 48075 pages in the wiki subdomain. But for purpose of this post, when I talk about the home page I'm talking about the contents of our main index.html and the most commonly visited pages directly linked to it, e.g., the why/download/product/get-involved, etc. pages. This core homepage content amounts to around 25 pages. Today this content is scattered around the content tree. Some of it is in the root. Some of it in /why and /download directories. Some of it is template-related and is in /templates rather than in - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
Brainstorming: Can we refactor the website to make translation easier?
(Responses to dev@openoffice.apache.org, please) Obviously our website is quite large. Google reports 21207 pages indexed in the www subdomain, and a further 48075 pages in the wiki subdomain. But for purpose of this post, when I talk about the home page I'm talking about the contents of our main index.html and the most commonly visited pages directly linked to it, e.g., the why/download/product/get-involved, etc. pages. This core homepage content amounts to around 25 pages. Today this content is scattered around the content tree. Some of it is in the root. Some of it in /why and /download directories. Some of it is template-related and is in /templates rather than in /content. As a test I tried to create my own NL page, in the fictitious xx locale. You can see it here: http://www.openoffice.org/xx/ It is not working correctly, but it already required a lot of non-trivial hacking: 1) I had to hunt around and guess which files to copy. Do I copy scripts, images and CSS, or just content pages? Some of the directories had out-dated content that was not linked to my anyone. It was hard to figure out what the minimum amount of content needed was, and where it was located. 2) The main index.html file had to be edited to refer to CSS in the root, rather than current directory 3) Download page is missed up, missing CSS and/or scripts. Presumably I need to copy something into the xx/download dir, or edit scripts to make them refer /download off the root. 4) The /xx/why pages are not showing the right side navigation now. I must have missed something there as well. Of course, I could figure the above out eventually. It just requires some time and effort and trial and error. But none of this is documented, and even if it were this is a fragile approach and probably beyond th web development skills of a typical translator. But we do know this has been done for some languages. They got it to work. The German page is a good example: http://www.openoffice.org/de/ Now this looks good, but it is still a messy thing from a maintenance perspective. If we make structural changes to the main English page, then those changes need to be manually merged into to every NL page. What can we do to improve this? Here's my idea: 1) What if we refactored the home page so it was all self-contained into these directories: /scripts, /styles, /images and /en/? 2) Make the /en directory be pure content. Only the stuff that needs to be translated. It loads everything else, scripts, images, etc., via URLs relative to the root, e.g.., in /scripts, /styles, etc. 3) Reduce or eliminate any embedded Javascript within pages. For example, refactor the code in download/index.html so it is external and depends on JSON resource files for translated strings. Aim so translators never need to touch script. 4) Ultimate goal is for someone to be able to jump start a new NL home page by simply requesting an svn copy of the /en directory, and then editing the resulting files. No one should ever need to do what I'm doing with the xx pages. 5) Maintenance is far easier. Most things like changing the scripts, is done in one place only. But even changes to the HTML are easier. Since we then have a common branch point via the svn copy, when structural changes are added to the main /en HTML, these can be merged in more elegantly to the translated versions, using Subversion. 6) Via Apache redirects we can ensure that the default call to www.openoffice.org/ goes to /en/. Conceivably we could also do locale detection and send requests automatically to the appropriate NL home page. A variation on the above would be to use Pootle, rather than svn copy/merge to maintain the translations. But that would require the same refactoring work to enable it. And it would require further investigation to identify a way of extracting and merging translation strings in MDText files as well as (X)HTML files. This is obviously more than a one-person task. So I'd be interested in hearing what you think in general about this approach, whether there is a simpler alternative I've missed, and whether this is something you'd be interested in helping with. Regards, -Rob - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
Re: Brainstorming: Can we refactor the website to make translation easier?
On 23 August 2013 17:58, Rob Weir robw...@apache.org wrote: (Responses to dev@openoffice.apache.org, please) Obviously our website is quite large. Google reports 21207 pages indexed in the www subdomain, and a further 48075 pages in the wiki subdomain. But for purpose of this post, when I talk about the home page I'm talking about the contents of our main index.html and the most commonly visited pages directly linked to it, e.g., the why/download/product/get-involved, etc. pages. This core homepage content amounts to around 25 pages. Today this content is scattered around the content tree. Some of it is in the root. Some of it in /why and /download directories. Some of it is template-related and is in /templates rather than in /content. As a test I tried to create my own NL page, in the fictitious xx locale. You can see it here: http://www.openoffice.org/xx/ It is not working correctly, but it already required a lot of non-trivial hacking: 1) I had to hunt around and guess which files to copy. Do I copy scripts, images and CSS, or just content pages? Some of the directories had out-dated content that was not linked to my anyone. It was hard to figure out what the minimum amount of content needed was, and where it was located. 2) The main index.html file had to be edited to refer to CSS in the root, rather than current directory 3) Download page is missed up, missing CSS and/or scripts. Presumably I need to copy something into the xx/download dir, or edit scripts to make them refer /download off the root. 4) The /xx/why pages are not showing the right side navigation now. I must have missed something there as well. Of course, I could figure the above out eventually. It just requires some time and effort and trial and error. But none of this is documented, and even if it were this is a fragile approach and probably beyond th web development skills of a typical translator. But we do know this has been done for some languages. They got it to work. The German page is a good example: http://www.openoffice.org/de/ Now this looks good, but it is still a messy thing from a maintenance perspective. If we make structural changes to the main English page, then those changes need to be manually merged into to every NL page. What can we do to improve this? Here's my idea: 1) What if we refactored the home page so it was all self-contained into these directories: /scripts, /styles, /images and /en/? 2) Make the /en directory be pure content. Only the stuff that needs to be translated. It loads everything else, scripts, images, etc., via URLs relative to the root, e.g.., in /scripts, /styles, etc. 3) Reduce or eliminate any embedded Javascript within pages. For example, refactor the code in download/index.html so it is external and depends on JSON resource files for translated strings. Aim so translators never need to touch script. 4) Ultimate goal is for someone to be able to jump start a new NL home page by simply requesting an svn copy of the /en directory, and then editing the resulting files. No one should ever need to do what I'm doing with the xx pages. 5) Maintenance is far easier. Most things like changing the scripts, is done in one place only. But even changes to the HTML are easier. Since we then have a common branch point via the svn copy, when structural changes are added to the main /en HTML, these can be merged in more elegantly to the translated versions, using Subversion. 6) Via Apache redirects we can ensure that the default call to www.openoffice.org/ goes to /en/. Conceivably we could also do locale detection and send requests automatically to the appropriate NL home page. A variation on the above would be to use Pootle, rather than svn copy/merge to maintain the translations. But that would require the same refactoring work to enable it. And it would require further investigation to identify a way of extracting and merging translation strings in MDText files as well as (X)HTML files. This is obviously more than a one-person task. So I'd be interested in hearing what you think in general about this approach, whether there is a simpler alternative I've missed, and whether this is something you'd be interested in helping with. I like a lot of your ideas, let me add my own experience. If the our pages do not contain text, but that is totally outsourced in one or more json objects, then translation becomes easy, and the pages themself stay simple. when the url is called without arguments the en-json is used, and if called with lang=xx xx-json is used. If we use json objects, then pootle becomes an elegant tool for translation, because it knows how to handle xml, and if we want to stay with po files its about 1 day work in genLang. A number of top companies (incl. the one I used to work for) do it like this, they of course then hire a translator to translate the json
Re: Brainstorming: Can we refactor the website to make translation easier?
On 23 August 2013 21:11, Rob Weir robw...@apache.org wrote: On Fri, Aug 23, 2013 at 12:21 PM, janI j...@apache.org wrote: On 23 August 2013 17:58, Rob Weir robw...@apache.org wrote: (Responses to dev@openoffice.apache.org, please) Obviously our website is quite large. Google reports 21207 pages indexed in the www subdomain, and a further 48075 pages in the wiki subdomain. But for purpose of this post, when I talk about the home page I'm talking about the contents of our main index.html and the most commonly visited pages directly linked to it, e.g., the why/download/product/get-involved, etc. pages. This core homepage content amounts to around 25 pages. Today this content is scattered around the content tree. Some of it is in the root. Some of it in /why and /download directories. Some of it is template-related and is in /templates rather than in /content. As a test I tried to create my own NL page, in the fictitious xx locale. You can see it here: http://www.openoffice.org/xx/ It is not working correctly, but it already required a lot of non-trivial hacking: 1) I had to hunt around and guess which files to copy. Do I copy scripts, images and CSS, or just content pages? Some of the directories had out-dated content that was not linked to my anyone. It was hard to figure out what the minimum amount of content needed was, and where it was located. 2) The main index.html file had to be edited to refer to CSS in the root, rather than current directory 3) Download page is missed up, missing CSS and/or scripts. Presumably I need to copy something into the xx/download dir, or edit scripts to make them refer /download off the root. 4) The /xx/why pages are not showing the right side navigation now. I must have missed something there as well. Of course, I could figure the above out eventually. It just requires some time and effort and trial and error. But none of this is documented, and even if it were this is a fragile approach and probably beyond th web development skills of a typical translator. But we do know this has been done for some languages. They got it to work. The German page is a good example: http://www.openoffice.org/de/ Now this looks good, but it is still a messy thing from a maintenance perspective. If we make structural changes to the main English page, then those changes need to be manually merged into to every NL page. What can we do to improve this? Here's my idea: 1) What if we refactored the home page so it was all self-contained into these directories: /scripts, /styles, /images and /en/? 2) Make the /en directory be pure content. Only the stuff that needs to be translated. It loads everything else, scripts, images, etc., via URLs relative to the root, e.g.., in /scripts, /styles, etc. 3) Reduce or eliminate any embedded Javascript within pages. For example, refactor the code in download/index.html so it is external and depends on JSON resource files for translated strings. Aim so translators never need to touch script. 4) Ultimate goal is for someone to be able to jump start a new NL home page by simply requesting an svn copy of the /en directory, and then editing the resulting files. No one should ever need to do what I'm doing with the xx pages. 5) Maintenance is far easier. Most things like changing the scripts, is done in one place only. But even changes to the HTML are easier. Since we then have a common branch point via the svn copy, when structural changes are added to the main /en HTML, these can be merged in more elegantly to the translated versions, using Subversion. 6) Via Apache redirects we can ensure that the default call to www.openoffice.org/ goes to /en/. Conceivably we could also do locale detection and send requests automatically to the appropriate NL home page. A variation on the above would be to use Pootle, rather than svn copy/merge to maintain the translations. But that would require the same refactoring work to enable it. And it would require further investigation to identify a way of extracting and merging translation strings in MDText files as well as (X)HTML files. This is obviously more than a one-person task. So I'd be interested in hearing what you think in general about this approach, whether there is a simpler alternative I've missed, and whether this is something you'd be interested in helping with. I like a lot of your ideas, let me add my own experience. Thanks. If the our pages do not contain text, but that is totally outsourced in one or more json objects, then translation becomes easy, and the pages themself stay simple. when the url is called without arguments the en-json is used, and if called with lang=xx xx-json is used. I like the idea of content/code separation. We certainly do this is the code,
Re: Brainstorming: Can we refactor the website to make translation easier?
On Fri, Aug 23, 2013 at 8:58 AM, Rob Weir robw...@apache.org wrote: (Responses to dev@openoffice.apache.org, please) Obviously our website is quite large. Google reports 21207 pages indexed in the www subdomain, and a further 48075 pages in the wiki subdomain. But for purpose of this post, when I talk about the home page I'm talking about the contents of our main index.html and the most commonly visited pages directly linked to it, e.g., the why/download/product/get-involved, etc. pages. This core homepage content amounts to around 25 pages. Today this content is scattered around the content tree. Some of it is in the root. Some of it in /why and /download directories. Some of it is template-related and is in /templates rather than in /content. As a test I tried to create my own NL page, in the fictitious xx locale. You can see it here: http://www.openoffice.org/xx/ It is not working correctly, but it already required a lot of non-trivial hacking: 1) I had to hunt around and guess which files to copy. Do I copy scripts, images and CSS, or just content pages? Some of the directories had out-dated content that was not linked to my anyone. It was hard to figure out what the minimum amount of content needed was, and where it was located. 2) The main index.html file had to be edited to refer to CSS in the root, rather than current directory Some of what you are experiencing re the css issues are due to many migrations and css that applies ONLY to the home page and not others. There's no reason why this should be this way really. SOme of us dealing with this on a day to day basis knew this but were afraid to mess with it. 3) Download page is missed up, missing CSS and/or scripts. Presumably I need to copy something into the xx/download dir, or edit scripts to make them refer /download off the root. 4) The /xx/why pages are not showing the right side navigation now. I must have missed something there as well. hmmm...not seeing what you've done, this could be do to some CMS setup. Of course, I could figure the above out eventually. It just requires some time and effort and trial and error. But none of this is documented, and even if it were this is a fragile approach and probably beyond th web development skills of a typical translator. But we do know this has been done for some languages. They got it to work. The German page is a good example: http://www.openoffice.org/de/ Now this looks good, but it is still a messy thing from a maintenance perspective. If we make structural changes to the main English page, then those changes need to be manually merged into to every NL page. What can we do to improve this? Here's my idea: 1) What if we refactored the home page so it was all self-contained into these directories: /scripts, /styles, /images and /en/? 2) Make the /en directory be pure content. Only the stuff that needs to be translated. It loads everything else, scripts, images, etc., via URLs relative to the root, e.g.., in /scripts, /styles, etc. 3) Reduce or eliminate any embedded Javascript within pages. I didn't think we had a lot of this but maybe more than we should. For example, refactor the code in download/index.html so it is external and depends on JSON resource files for translated strings. Aim so translators never need to touch script. Well I don't really know JSON so I can't speak to this. Will investigate. though we do/did make extensive use of JS data structures in the past. 4) Ultimate goal is for someone to be able to jump start a new NL home page by simply requesting an svn copy of the /en directory, and then editing the resulting files. No one should ever need to do what I'm doing with the xx pages. I think once upon a time -- maybe LONG ago -- the NL pages were standardized to be clone of the main index page. But, various NL groups wanted more of their own identity, and so we have what we have. 5) Maintenance is far easier. Most things like changing the scripts, is done in one place only. But even changes to the HTML are easier. Since we then have a common branch point via the svn copy, when structural changes are added to the main /en HTML, these can be merged in more elegantly to the translated versions, using Subversion. 6) Via Apache redirects we can ensure that the default call to www.openoffice.org/ goes to /en/. Conceivably we could also do locale detection and send requests automatically to the appropriate NL home page. A variation on the above would be to use Pootle, rather than svn copy/merge to maintain the translations. But that would require the same refactoring work to enable it. And it would require further investigation to identify a way of extracting and merging translation strings in MDText files as well as (X)HTML files. This is obviously more than a one-person task. So I'd be interested in hearing what you think in general about
Re: Brainstorming: Can we refactor the website to make translation easier?
Hi, Em 23/08/2013 16:58, Rob Weir escreveu: (Responses to dev@openoffice.apache.org, please) As a test I tried to create my own NL page, in the fictitious xx locale. You can see it here: http://www.openoffice.org/xx/ 1) I had to hunt around and guess which files to copy. Do I copy scripts, images and CSS, or just content pages? Some of the directories had out-dated content that was not linked to my anyone. It was hard to figure out what the minimum amount of content needed was, and where it was located. Likewise here with the Portugal site! 2) The main index.html file had to be edited to refer to CSS in the root, rather than current directory 3) Download page is missed up, missing CSS and/or scripts. Presumably I need to copy something into the xx/download dir, or edit scripts to make them refer /download off the root. 4) The /xx/why pages are not showing the right side navigation now. I must have missed something there as well. I suppose that's why I had to ask for help on the download link. Of course, I could figure the above out eventually. It just requires some time and effort and trial and error. But none of this is documented, and even if it were this is a fragile approach and probably beyond th web development skills of a typical translator. Couldn't agree more! 1) What if we refactored the home page so it was all self-contained into these directories: /scripts, /styles, /images and /en/? 2) Make the /en directory be pure content. Only the stuff that needs to be translated. It loads everything else, scripts, images, etc., via URLs relative to the root, e.g.., in /scripts, /styles, etc. Being a ignorant as I am, seems a lot more simple, anyone could choose what to do with the localized site accordingly to its own skills. This is obviously more than a one-person task. So I'd be interested in hearing what you think in general about this approach, whether there is a simpler alternative I've missed, and whether this is something you'd be interested in helping with. As I'm not a developer or programmer but just a curious, I'm whiling to help in every way possible. So I'll give my opinion. I think that basically there are not many mandatory things to be in an official localized site. Those should be automatically inserted (I think that they already are). Other than that, a simple request to translate the /en directory (if this is the localized one) should be enough for most translators, and allow a continuous maintenance of the site for those available without much trouble for them. A simple warning mail would suffice. To go a little bit further, maybe a list of the links in the site should be mandatory and perfectly distinguished from others (local ones) and automatically updated so that someone like me doesn't have to test all the previously existing ones just to verify that most of them are broken or out of date. Besides this, for the experts or others alike, there should be an option, somewhere, to create or upload (?) there own ideas. Subject to approval from the responsible (the one in charge;-) ), of course. Above all, please keep it simple. Best regards, Pedro - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
Re: Brainstorming: Can we refactor the website to make translation easier?
Starting re-factoring from en is a good idea. And automating translation
of the various pages is even greater, but I think we should prepare and
restructure content for this first (I don't mean only technical
restructuring).
I think the home page could be greatly simplified to contain much less
text while being even more useful (would be more focused). That would
also make it very quickeasy to translate and to maintain. Also
openoffice.apache.org seems largely like a duplicate of
www.openoffice.org. De-duplication of information and deciding what goes
where would be great (also great for translation). Did you know for
example that after de-duplication the gov.uk website it went from 70k to
only 3k pages! Imagine how much easier it is to maintain it. Would be
nice if you could get Sara Wachter-Boettcher to help. I've seen her
presentation on Mobilism about structuring data of companies and she
seem to have already done things like OpenOffice website(s) needs. Not
sure if she works pro bono though and (if she doesn't) I don't know if
AOO has a budget for things like that.
Anyway here's my taking on restructuring data/content.
* Home page
o Download link (much like it is already done on the download page).
o Composition of screenshots of the latest version (not
necessarily in native language, but would be cool if automated).
Something like a hand of cards showing the Writer and the Calc
on the sides and maybe the welcome page in the middle but in the
bottom layer. Or maybe whole suite showing example documents?
o On the right there should only be links that are now on the left
(I want/need links).
o Below all that I would make 3 boxes (side-by-side) with the
boxes from the download page (Help Spread the Word, Extensions
and Dictionaries and Templates).
* Overview page
o The link I want to learn more about OpenOffice should point here.
o Content of the main page of why seems to be duplicate of the
main page of product. I actually like product page more.
o Add link to why in More submenu of the overview page.
o So maybe just keep the product page and call it overview.
* News page
o The link I want to stay in touch with OpenOffice should point
here.
o News on the left (would be cool if news could be posted in many
languages and a single language would get en-news and native news).
o Blog posts on the right (similar sidebar that is on the right on
the main page).
* Get involved page
o The link I want to participate in OpenOffice should point here.
o Should be a short page.
o I think I translated this so this is actually already in the
Pottle - would be great to just use that (maybe with a bit of
transformation e.g. parsing text URLs into HTML tags).
o Add information about Pottle itself (or was it there already - I
don't remember).
* Menu
o Overview (as described)
o Download (as-is) - would be partially a duplicate of new home,
but I believe it's OK here as it is generated anyway.
o Support (as-is)
o News (as described)
o Get involved (as described)
o Remove other - here's why:
+ Blog - external site; just keep links on the news page
+ Extend - duplicate of things on the download page
+ Develop - already on the main page and would be on get
involved page; also it is a de facto external website
+ Focus Areas - remove doesn't seem very interesting for a
regular user - maybe you could move it to openoffice.apache.org.
+ Native Language - this doesn't seem to be very useful -
would be useful only if integrated with Pottle (giving
information on current progress of translation).
Other stuff
* Language switch - should be automatic and optionally there could be
a switch above the menu on the right.
* Search should be bigger (at least a bit wider).
* Links to an external site should indicate they are external.
Wikipedia has a quite nice way of doing that and it only requires a
single CSS rule for all browsers that count.
Translation
* I think would could use Pottle for basic strings with an addition of
some transforming scripts.
o po files could e.g. be translated to JSON style objects for
JavaScript (if needed).
o to make the site static we could pre-render HTML directly from
po files treating HTML files as templates (e.g. replace
{{Product}} with it's translation)
o templates would still be standard HTML files and so CMS/SVN
could still be used to edit what would now be templates
(whatever CMS you are using - it would just edit different
things that are shown)
* Pushing changes
o you could then add a job to CMS to render page (or pages) - this
would just run prepared scripts
o ...or use Jenkins for
