public inbox for linux-doc@vger.kernel.org
 help / color / mirror / Atom feed
From: Federico Vaga <federico.vaga@vaga.pv.it>
To: Jonathan Corbet <corbet@lwn.net>
Cc: linux-doc@vger.kernel.org, amantegazza@vaga.pv.it
Subject: Re: Documentation/translations: Italian
Date: Tue, 22 May 2018 10:39:09 +0200	[thread overview]
Message-ID: <3094464.Q0nrLVF18W@pcbe13614> (raw)
In-Reply-To: <20180521170035.7e75f54b@lwn.net>

On Tuesday, 22 May 2018 01:00:35 CEST Jonathan Corbet wrote:
> On Mon, 21 May 2018 22:54:18 +0200
> 
> Federico Vaga <federico.vaga@vaga.pv.it> wrote:
> > I'm writing you because I would like to start an effort to
> > translate the Documentation in Italian. I would like also to
> > express the idea of providing guide lines for translations.
> 
> Mi sembra un'ottima idea! :)

Siamo sulla stessa lunghezza d'onda :)
 
> > I know that there are already translations for Asian languages but
> > I am not able to find the history of them. I do not know if
> > translations in European languages are going to be accepted
> > (perhaps there is the assumption that everyone knows English in
> > the European continent and it is a waste of energy to do
> > translations[?]). For example, even if French and Germans are
> > quite active there are not translations yet in their language: is
> > there a particular reason or simply nobody did it?
> 
> Nobody has done it.  There certainly is no policy against
> translations to any specific language - that would be hard to
> justify, to say the least.
> 
> OK, I might draw the line at Klingon.  But the discussion of error
> handling in Klingon could actually be a lot of fun.
> 
> I'm happy to accept new translations of stuff in the documentation
> directory.  In general, I've had two concerns about translations:
> they are generally impossible for me to review, and there needs to
> be somebody committed to keeping the translations current as the
> documentation changes.  For Italian, the first problem doesn't
> exist, but the second is always there. What are your intentions for
> maintaining the translations in the long term?

I can maintain the Italian translation. 
 
> > If you agree with the need to support different translations, I
> > would like to do the Italian one. But first I would like to open
> > a little discussion about translations  "how to write
> > translations"; this discussion should produce a document (in
> > English) with guide lines for translator (e.g. Documentation/
> > translation/howto.rst): what to translate first, what to NOT
> > translate, how to structure it.
> > Once this is defined I will start the Italian translation (I
> > already have some documents translated).
> 
> This can be a fine plan, assuming we're convinced that the
> guidelines document is really needed.  I guess I'm not yet
> convinced of that.  But you might also consider gaining some
> experience in writing, merging, and maintaining a translation
> before trying to lay down rules for everybody else.  In other
> words, I think you might want to do things in the opposite order.

You are right, probably I was over-engineering this thing :)

> 
> > How to do translations (IMHO)
> > -----------------------------
> > Here my personal guide lines for translations
> > 
> > - Translate only sphinx-ready documents, do not translate
> > documents which are not yet sphinx. We should avoid useless
> > double work; at some point, I guess, everything will be sphinx.
> 
> I wouldn't insist on that.  But a better idea in any case would be:
> if a document you want to translate isn't yet in RST, just do the
> conversion. The amount of work required is usually quite small.

ok

> > - Include in all documents a disclaimer saying that English is the
> > main reference (use sphinx directive 'include' to include it).
> > - Include in all documents a reference to the English version. So
> > it will be easy jump to the original document.
> 
> Remember that the docs need to be readable *without* Sphinx
> processing. Better to just name the source document in a quick line
> at the top, IMO.

ok

> > - Translate in order: non-technical documents (they are stable,
> > useful for a wider group of people (developers and managers):
> > process/, doc-guide/ ), technical documents about key concepts
> > (they are stable, and important for new-comers), subsystems (the
> > big picture is stable, typically they do not describe all little
> > details that may change), and then other documents
> If you want to work in that order, that is more than fine.  Others
> have agreed - the process docs tend to get translated first.  But
> if somebody else wants to start elsewhere, I wouldn't try to tell
> them not to.
> 
> Anyway, thanks for wanting to help improve the documentation!  If
> you have some of this work already done, you might want to consider
> going ahead and posting some patches.

I will review them and push something in the next days

-- 
Federico Vaga
http://www.federicovaga.it/


--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

      reply	other threads:[~2018-05-22  8:39 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-05-21 20:54 Documentation/translations: Italian Federico Vaga
2018-05-21 23:00 ` Jonathan Corbet
2018-05-22  8:39   ` Federico Vaga [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=3094464.Q0nrLVF18W@pcbe13614 \
    --to=federico.vaga@vaga.pv.it \
    --cc=amantegazza@vaga.pv.it \
    --cc=corbet@lwn.net \
    --cc=linux-doc@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox