Re: Adding Japanese README

I would like to propose to add Japanese translated version of README
in the source tree(for example against backend/storage/buffer/README).
Benefits of our community include:

- Increase possibility to hire more Japanese speaking developers by
helping them to understand source code using those README written in
their local language

- Make Japanese speaking developers life easier. Most of them can read
English README of course. However, reading Japanese one will
increase their productivity thus more contribution to PostgreSQL

- Including Japanese README in the source tree rather than placing in
somewhere else helps syncing English README with Japanese one.

Please note that I am not against adding README translated in other
language. I just don't understand other than Japanese.

Comments?
--
Tatsuo Ishii
SRA OSS, Inc. Japan
English: http://www.sraoss.co.jp/index_en.php
Japanese: http://www.sraoss.co.jp

Tatsuo Ishii <ishii(at)postgresql(dot)org> wrote:

> I would like to propose to add Japanese translated version of
> README in the source tree

> Comments?

The obvious concern would be "drift". As README files are patched,
someone would need to stay on top of the translation process. Any
ideas on how that could be reasonably managed?

-Kevin

Tatsuo Ishii <ishii(at)postgresql(dot)org> writes:
> I would like to propose to add Japanese translated version of README
> in the source tree(for example against backend/storage/buffer/README).

I think this is basically a bad idea, because 90% of the developers will
be unable to update such a file when changing the source code, or even
verify whether it's an accurate translation. Thus it will inevitably
become out-of-date, and that seems worse than useless. I'm fairly
dubious that someone who doesn't read English will be able to make much
sense of the source code anyway.

> Please note that I am not against adding README translated in other
> language. I just don't understand other than Japanese.

That's another problem: if we add Japanese, why not six or seven other
languages?

regards, tom lane

>> I would like to propose to add Japanese translated version of
>> README in the source tree
>
>> Comments?
>
> The obvious concern would be "drift". As README files are patched,
> someone would need to stay on top of the translation process. Any
> ideas on how that could be reasonably managed?

My idea is defining "maintainer" for each README. Of course I am ready
for Japanese one.
--
Tatsuo Ishii
SRA OSS, Inc. Japan
English: http://www.sraoss.co.jp/index_en.php
Japanese: http://www.sraoss.co.jp

Excerpts from Tom Lane's message of mié jun 29 19:24:07 -0400 2011:
> Tatsuo Ishii <ishii(at)postgresql(dot)org> writes:
> > I would like to propose to add Japanese translated version of README
> > in the source tree(for example against backend/storage/buffer/README).
>
> I think this is basically a bad idea, because 90% of the developers will
> be unable to update such a file when changing the source code, or even
> verify whether it's an accurate translation. Thus it will inevitably
> become out-of-date, and that seems worse than useless. I'm fairly
> dubious that someone who doesn't read English will be able to make much
> sense of the source code anyway.

What we could do instead is add a link to a translation in the wiki,
with a note that the wiki page may not be up to date.

--
Álvaro Herrera <alvherre(at)commandprompt(dot)com>
The PostgreSQL Company - Command Prompt, Inc.
PostgreSQL Replication, Consulting, Custom Development, 24x7 support

Tatsuo Ishii <ishii(at)postgresql(dot)org> wrote:

>> The obvious concern would be "drift". As README files are
>> patched, someone would need to stay on top of the translation
>> process. Any ideas on how that could be reasonably managed?
>
> My idea is defining "maintainer" for each README. Of course I am
> ready for Japanese one.

That would only cover part of the problem, and not on a permanent
basis.

How do you notice that a README has changed?

How does the community know when the changes have been completely
incorporated into the translation?

What do we do if we have README translations which haven't been
updated when it's time to tag a release? Delete them? Leave old,
misleading content?

What if you move on to something else and are no longer active in
the project?

I think this needs a well-defined and sustainable *process*, not
just a set of volunteers. I'm skeptical that a workable process can
be devised, but I'm willing to be proven wrong.

Now, if someone wanted to set up a web site or Wiki page with
translations, that would be up to them. I doubt anyone would object
to a link from the Developer FAQ to such a page. It seems to me
that this would provide most of the same benefit, without much in
the way of a down side. It might be wise to go so far as to put a
"last modified" date in each README (which would be copied without
change into each translation which brought things up to date), so
that it would be easy for someone looking at translation to
determine whether it was current.

-Kevin

> I think this is basically a bad idea, because 90% of the developers will
> be unable to update such a file when changing the source code, or even
> verify whether it's an accurate translation. Thus it will inevitably
> become out-of-date, and that seems worse than useless. I'm fairly
> dubious that someone who doesn't read English will be able to make much
> sense of the source code anyway.

This is the same argument as Kevin raised. My idea is defining
"maintainer" for each non English README who is responsible for
updating in timely manner. If the mainter is too lazy, we would be
able to remove the file before releasing new version. In another word,
the released version of PostgreSQL will always have accurate README,
which itself valuable for those who are in charge of maintaining older
versions.

>> Please note that I am not against adding README translated in other
>> language. I just don't understand other than Japanese.
>
> That's another problem: if we add Japanese, why not six or seven other
> languages?

That's basically the same problem as message translation. If we have
to wait until six or seven langugae speakers appear before putting
Japanese README written in particular language, why didn't do that way
for message translation? It seems your argument is not fair here.
--
Tatsuo Ishii
SRA OSS, Inc. Japan
English: http://www.sraoss.co.jp/index_en.php
Japanese: http://www.sraoss.co.jp

>> My idea is defining "maintainer" for each README. Of course I am
>> ready for Japanese one.
>
> That would only cover part of the problem, and not on a permanent
> basis.
>
> How do you notice that a README has changed?

Commit messages, obviously.

> How does the community know when the changes have been completely
> incorporated into the translation?

Why don't you worry about message translations then? Translation is a
human process and there's no way to guaranteer the translation is
perfect.

> What do we do if we have README translations which haven't been
> updated when it's time to tag a release? Delete them? Leave old,
> misleading content?

I would say delete them. The reson for this is:

> If the mainter is too lazy, we would be
> able to remove the file before releasing new version. In another word,
> the released version of PostgreSQL will always have accurate README,
> which itself valuable for those who are in charge of maintaining older
> versions.

> What if you move on to something else and are no longer active in
> the project?
>
> I think this needs a well-defined and sustainable *process*, not
> just a set of volunteers. I'm skeptical that a workable process can
> be devised, but I'm willing to be proven wrong.

Kevin, this is an open source project. Nobody can guarantee that
he/she can continute to contribute forever. If we are so worry about
this, we will never be able to accept any contribution at all.

BTW I will talk to some Japanese speaking developers about my idea if
community agree to add Japanese README to the source tree so that I am
not the only one who are contributing this project(I can commit that
my coworkers will help the project. However I prefer to gather
contributors outside my company in addition to inside my company since
this will bring more sustainable activity).

> Now, if someone wanted to set up a web site or Wiki page with
> translations, that would be up to them. I doubt anyone would object
> to a link from the Developer FAQ to such a page. It seems to me
> that this would provide most of the same benefit, without much in
> the way of a down side. It might be wise to go so far as to put a
> "last modified" date in each README (which would be copied without
> change into each translation which brought things up to date), so
> that it would be easy for someone looking at translation to
> determine whether it was current.
--
Tatsuo Ishii
SRA OSS, Inc. Japan
English: http://www.sraoss.co.jp/index_en.php
Japanese: http://www.sraoss.co.jp

On Thu, Jun 30, 2011 at 09:42, Tatsuo Ishii <ishii(at)postgresql(dot)org> wrote:
> BTW I will talk to some Japanese speaking developers about my idea if
> community agree to add Japanese README to the source tree so that I am
> not the only one who are contributing this project
>
>> Now, if someone wanted to set up a web site or Wiki page with
>> translations, that would be up to them.

IMHO, the Wiki approach seems to be reasonable than a README file.
It will be suitable for adding non-Japanese translations and
non-core developer can join to translate or fix the docs.

If we will promote those README files as documentation, we could
move them into "internals" section in the SGML doc tree. If so,
the translated README will be a part of the doc translation project.

--
Itagaki Takahiro

> IMHO, the Wiki approach seems to be reasonable than a README file.
> It will be suitable for adding non-Japanese translations and
> non-core developer can join to translate or fix the docs.

I doubt other than developers can translate those README files since
the words used in the files chosen to be understandable for those who
are familiar with PostgreSQL internals.
--
Tatsuo Ishii
SRA OSS, Inc. Japan
English: http://www.sraoss.co.jp/index_en.php
Japanese: http://www.sraoss.co.jp

On Thu, Jun 30, 2011 at 10:43 AM, Tatsuo Ishii <ishii(at)postgresql(dot)org> wrote:

> > IMHO, the Wiki approach seems to be reasonable than a README file.
> > It will be suitable for adding non-Japanese translations and
> > non-core developer can join to translate or fix the docs.
>
> I doubt other than developers can translate those README files since
> the words used in the files chosen to be understandable for those who
> are familiar with PostgreSQL internals.
>
You may be surprised by the quality of translations from non-developers
findable in a lot of Open source softwares.

--
Michael Paquier
http://michael.otacoo.com

2011/6/30 Itagaki Takahiro <itagaki(dot)takahiro(at)gmail(dot)com>:
> On Thu, Jun 30, 2011 at 09:42, Tatsuo Ishii <ishii(at)postgresql(dot)org> wrote:
>> BTW I will talk to some Japanese speaking developers about my idea if
>> community agree to add Japanese README to the source tree so that I am
>> not the only one who are contributing this project
>>
>>> Now, if someone wanted to set up a web site or Wiki page with
>>> translations, that would be up to them.
>
> IMHO, the Wiki approach seems to be reasonable than a README file.
> It will be suitable for adding non-Japanese translations and
> non-core developer can join to translate or fix the docs.

+1. If we really want to prove the demand, let's start with Wiki,
which is less invasive than README (though I doubt such pages would be
updated finally.)

Regards,

--
Hitoshi Harada

On ons, 2011-06-29 at 18:48 -0500, Kevin Grittner wrote:
> I think this needs a well-defined and sustainable *process*, not
> just a set of volunteers. I'm skeptical that a workable process can
> be devised, but I'm willing to be proven wrong.

We had translated FAQs, each with a maintainer, which were massively
outdated before we removed them.

And just as another example closer to home, I can tell even without
knowing any Japanese or Chinese that doc/README.mb.big5 and
doc/README.mb.jp are so outdated that we should consider removing them
right now.

On tor, 2011-06-30 at 09:42 +0900, Tatsuo Ishii wrote:
> Why don't you worry about message translations then? Translation is a
> human process and there's no way to guaranteer the translation is
> perfect.

At least for message translations we have a process and sophisticated
tools that ensure that the translation has been done and when and by
whom. If you create additional translation maintenance effort, then if
you could integrate that into the existing PO-based system, I'm sure the
objections would be less (or different).

And another important point: the PO-based system never shows outdated
translations to the user.

But if we're adding another step to the release preparation where
someone has to chase down half a dozen people to update some file, that
creates a lot more burden and bottlenecks, including the possibility to
hold up minor releases or having to remove files in minor releases.

On Thu, Jun 30, 2011 at 1:49 AM, Hitoshi Harada <umi(dot)tanuki(at)gmail(dot)com> wrote:
> 2011/6/30 Itagaki Takahiro <itagaki(dot)takahiro(at)gmail(dot)com>:
>> On Thu, Jun 30, 2011 at 09:42, Tatsuo Ishii <ishii(at)postgresql(dot)org> wrote:
>>> BTW I will talk to some Japanese speaking developers about my idea if
>>> community agree to add Japanese README to the source tree so that I am
>>> not the only one who are contributing this project
>>>
>>>> Now, if someone wanted to set up a web site or Wiki page with
>>>> translations, that would be up to them.
>>
>> IMHO, the Wiki approach seems to be reasonable than a README file.
>> It will be suitable for adding non-Japanese translations and
>> non-core developer can join to translate or fix the docs.
>
> +1. If we really want to prove the demand, let's start with Wiki,
> which is less invasive than README (though I doubt such pages would be
> updated finally.)

We could consider adding a note to the README files pointing people to
an appropriate wiki page for translated versions, so that someone who
just checks out the source tree has a place to go and start looking.

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company