Le 28/11/2010 15:14, Carl Sorensen disait :
On 11/28/10 7:08 AM, "Valentin Villenave" wrote:
Hi Jean-Charles, greetings everybody,
I've been working on a patch for fr.po but I have a few questions:
- how do we register at the Translation Project? (actually, I'd
prefer not to bother with it at all, I'd rather send you my patch and
let you review it and upload it for me :)
After having registered to the FTP (send the disclaimer for certain
"domains" and wait for acknowledgment), you have to send your po file to
the "translation robot". As long as you aren't assigned to a domain, you
contribution will be rejected. Once your file has been accepted by the
robot, lilypond-devel is notified that a new version for this language
is available (like
http://lists.gnu.org/archive/html/lilypond-devel/2010-11/msg00530.html).
The translation master will then integrate it into the source tree.
- I noticed that several strings were'nt i18n in Lily's source code.
Is there a reason for that? If it's just a matter of enclosing these
in (_ "") or (_f "%s"), I can submit a patch for it. If there's a
policy about it (e.g. "translate warnings but not progerrors", or
something like that) then I can't remember having seen it in the CG
(in which case I may /also/ submit a patch :)
See section 9.5.8 Localization for the policy on localization.
Programming_error () programming_warning () are not to be localized. But
regular errors and warnings are.
I consider that what might help the user to "correct" the input in order
to compile his score successfully might be worth a warning. On the other
hand, not everybody in the bug-squad is fluent in Javanavanaivais...
I currently have a patch up for approval that fixes this problem in the fret
calculation section of scm/translation-functions.scm. So please don't patch
those; I'd rather not have to deal with the merge conflicts.
- I also noticed that some strings in the .po files are actually not
in the source files: for example, have a look at fr.po line 1389. Why
is that? do we need to run xgettext or something?
Do you mean:
#: context-def.cc:130
#, c-format
msgid "program has no such type: `%s'"
msgstr "Le programme n'a pas de tel type : « %s »"
?
If you have a look at http://translationproject.org/domain/lilypond.html
you'll see that the template file is as of 2.13.7, which means that
anything that has disappeared form the sources will remain in the record
and what has been amended or added since then is absent.
As a matter of fact, any major version should be preceded by an upload
of a new template (assignees get automatically acknowledged by the FTP)
in order to have an up to date set of translated messages.
- speaking of the CG, maybe it would be better to have "Translation
Work" as a top-level section, so that we could move there everything
related to "Website translation", "Documentation translation", and add
a "Program translation" subsection as well?
What would be in the "Program translation" section? In general, do we want
to translate the source code?
"Program translation" is not worth a specific chapter: programmers
establish a form of dialog between the user and the program, through the
console or a log-file, that may be considered in parallel with commented
source.
Non-English users may influence naming of options or variables in order
to be "consistent" with the various languages (like lately with spacing
and my warning in the French docs: "English consider a blank on the
right when we have an alignment to the left. So, don't be frightened
when ragged-right puts it on the left!"). More important is how the
message is labeled.
I even consider that comments in the snippets might be worth some policy...
HTH,
Jean-Charles
_______________________________________________
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
