On Mon, Jul 2, 2012 at 2:27 PM, Rob Weir <robw...@apache.org> wrote:
> On Mon, Jul 2, 2012 at 4:20 PM, Kay Schenk <kay.sch...@gmail.com> wrote:
> > On Mon, Jul 2, 2012 at 7:14 AM, Rob Weir <robw...@apache.org> wrote:
> >
> >> On Mon, Jul 2, 2012 at 9:57 AM, Donald Whytock <dwhyt...@gmail.com>
> wrote:
> >> > You don't have to use Google Translate for the entire site into a
> >> > given language. Better than no page at all in a given language is a
> >>
> >> True. To enable this integration requires adding markup to two
> >> places in the HTML file:
> >>
> >> 1) Load some script in the <head> section
> >>
> >> 2) Add a Google-provided <div> to wherever in the page we want the
> >> language selector drop down to be.
> >>
> >> It would be really easy to add this to a small number of selected pages.
> >>
> >> It would also be easy to add to all pages via the CMS template.
> >>
> >> What would be hard is managing this for a large number of pages, but
> >> not all pages.
> >>
> >> > page in a given language that says, "Hi there! This is the site for
> >> > Apache OpenOffice. We welcome translations of our site into your
> >> > language, and invite you to volunteer at the following email address:
> >> > <blah> Or you can submit a translation through Google Translate, which
> >> > was used to produce this page."
> >> >
> >> > Something as short as that is less likely to be garbled in
> >> > auto-translation than something technical, and it tells potential
> >> > contributors what to do to help out.
> >> >
> >>
> >> The trick would be to get people to visit that page. Unless it was on
> >> the home page.
> >>
> >> -Rob
> >>
> >> > Don
> >>
> >
> > OK, it took me a little while to weed through Google's info on this.
> >
> > A good sample can be found at:
> >
> >
> http://googleblog.blogspot.com/2009/09/translate-your-website-with-google.html
> >
> > Is there any possibility we could ad the gadget to the OOo blogs site --
> >
> > https://blogs.apache.org/OOo/
> >
> > just for fun and see what we think?
> > This way we'd just be impacting one page and not a whole site.
> >
>
> If we want access to review and approve suggestions made by readers
> then it needs to be on a domain that we "own". This is in common with
> most Google services, you need to demonstrate that you control the
> domain, typically by adding a special META tag to the homepage. For
> *.openoffice.org this is easy, and I've already done this to enable
> Google Analytics. If we want to do the same for the blog we'd need
> the ability to insert special markup into the <head> and <body> of the
> blog template. I'm not sure whether this is possible with our Roller
> setup.
>
oh -- well too bad. It could have been fun.
>
> Another way of testing this, in a quantitative way, is via what is
> called "A/B Testing". With this approach we define an action a
> satisfied site visitor might take, like downloading AOO 3.4. Then we
> randomly show users either the original home page (or download page or
> any other page we're testing). This is "A", and then we show other
> users a different version, B. For example, B could have the
> translation enabled. Then we ran this "experiment" for a period of
> time, like a week or two, tracking which version of the page has the
> higher success rate with users.
>
hmmmm...interesting
OK, I've looked at the rest of your post here and will think about this for
a bit.
>
> If the machine translated page leads visitors confuses users, or makes
> them suspect the page, then the download %'s will be lower than the
> original page. And if the translated page is helpful then the
> download numbers would be higher.
>
> You could imagine other success indicators. Pretty much anything that
> has a URL can be measured. For example, imagine we add a link, "This
> page solved my problem" to the bottom of every documentation page.
> Even though the link would just go to a "thanks" page, we could use
> that action to measure the success of translated versus untranslated
> pages.
>
> Of course, we don't need to do this all at once. But I'd recommend we
> think of ways of quantifying success. The website serves our users.
> How do we know what is working well and what isn't? How can we design
> experiments to test alternative approaches?
>
>
> Possible successes for users might be:
>
> - downloaded AOO
>
> - found answer to their question
>
> - signed up for our announcement list
>
> - entered their first bug report
>
> - signed up for one of the project lists
>
> - make first wiki contribution
>
> - followed/liked/+1'ed us on one of our social networking sites
>
> Measure, improve, repeat. Constant improvement and optimization.
>
> We can debate what will improve the website for the users. Or we can
> test and measure. A/B testing is a new option for us, a technique
> that once was used only by the largest commercial websites, but is now
> available to everyone via Google's "content experiments" support in
> Google Analytics.
>
> -Rob
>
> > I think that might a perfect application for something like this.
> >
> >
> >
> > --
> >
> ----------------------------------------------------------------------------------------
> > MzK
> >
> > "I would rather have a donkey that takes me there
> > than a horse that will not fare."
> > -- Portuguese proverb
>
--
----------------------------------------------------------------------------------------
MzK
"I would rather have a donkey that takes me there
than a horse that will not fare."
-- Portuguese proverb
