All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Shawn O. Pearce" <spearce@spearce.org>
To: Johannes Schindelin <Johannes.Schindelin@gmx.de>
Cc: Christian Stimming <stimming@tuhh.de>,
	Miklos Vajna <vmiklos@frugalware.org>,
	Nanako Shiraishi <nanako3@bluebottle.com>,
	Michele Ballabio <barra_cuda@katamail.com>,
	Paolo Ciarrocchi <paolo.ciarrocchi@gmail.com>,
	Xudong Guan <xudong.guan@gmail.com>,
	Harri Ilari Tapio Liusvaara <hliusvaa@cc.hut.fi>,
	Junio C Hamano <gitster@pobox.com>,
	Irina Riesen <irina.riesen@gmail.com>,
	git@vger.kernel.org
Subject: Re: git-gui i18n status?
Date: Sat, 1 Sep 2007 21:42:42 -0400	[thread overview]
Message-ID: <20070902014242.GJ18160@spearce.org> (raw)
In-Reply-To: <Pine.LNX.4.64.0709020003480.28586@racer.site>

Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:
> On Sat, 1 Sep 2007, Shawn O. Pearce wrote:
> > Looking at the repository on repo.or.cz it looks like it needs to be 
> > merged/rebased onto 0.8.2.  There is a trivial merge conflict, but there 
> > are some more subtle ones caused by the movement of the library 
> > directory initialization down lower in git-gui.sh. For example 
> > translations won't be initialized if we have an issue with the output of 
> > git-version and want to prompt the user.
> 
> Hmm.  I am not enough involved in i18n stuff to form a proper opinion 
> here...  Do you suggest to move the initialisation earlier?

Yea, I think that's what we are going to have to do here.  If we don't
setup the directory for the .msg files early enough than we cannot do
translations through [mc].  Unfortunately that means we have to also
break up the library initialization.

I'll try to work up a patch that does this.
 
> > What is the current plan?  Should I be looking at the master branch of 
> > git://repo.or.cz/git-gui/git-gui-i18n.git for pulling?  Or are folks 
> > expecting that this series will be cleaned up before I pull it?
> 
> My plan is to put out a cleaned up patch series:
...
> All these patches will go through the mailing list, so that people can 
> comment and suggest improvements.

OK, that works well for me.  Nice clean series to apply.
 
> I'll also try to bug Christian into looking through the output of
> 
> 	git grep \" -- \*.sh \*.tcl | grep -vwe mc -e bind | less
> 
> to make sure that we did not forget a string.  ATM the output consists of 
> 300+ lines, so it is a bit boring.  Maybe I can improve that command, 
> too...

Some of these are internal errors that should never be presented to
an end-user, and some are for reflog entries.   Here's a quick run
through of these:

      D == internal error message (developer only)
      R == reflog message
      T == probably should be translated

 D  "Invalid arguments to git-version",
 D  "Last arm of $type $name must be default",
 D  "git-version >= x",
 T  "git-gui: fatal error",
 T  "Cannot move to top of working directory:\n\n$err",
 D  "error: no icon for $w state={$state} $path",
 D  "error: no desc for state={$state} $path",
 T  "Unstaging [short_path $path] from commit",
 T  "Adding [short_path $path]",
 T  "fatal: cannot stat path $path: No such file or directory",
 T  "Possible environment issues exist.[...]",
 T  "Loading$cur_s annotations...",
 T  "Loading annotation...",
 T  "Author:\t",
 T  "Committer:\t",
 T  "Original File:\t",
 T  "Originally By:\n",
 T  "In File: ",
 T  "Copied Or Moved Here By:\n",
 T  "fatal: Cannot resolve $l_trck",
 R  "branch: Created from $new_expr",
 R  "merge $new_expr: Fast-forward",
 T  "Updating working directory to '[_name $this]'...",
 T  "Checked out '$name'.",
 D  "class $class already declared",
 D  "wrong # args: field name value?",
 D  "class $class is sealed (cannot add new fields)",
 D  "field $name already declared",
 D  "wrong # args: method name args body (ifdeleted body)?",
 D  "make_toplevel topvar winvar {options}",
 D  "unsupported option $name",
 T  "Commit $PARENT appears to be corrupt",
 T  "warning: Tcl does not support encoding '$enc'.",
 T  "This repository currently has approximately [...]",
 T  "Loading diff of [escape_path $path]...",
 T  "Unable to display [escape_path $path]",
 T  "* Binary file (not showing content).",
 T  "Unable to display [escape_path $path]",
 D  "error: Unhandled 3 way diff marker: {$op}",
 D  "error: Unhandled 2 way diff marker: {$op}",
 T  "Unstaging [short_path $current_diff_path] from commit",
 T  "Adding [short_path $current_diff_path]", and
 T  "The following branches are not completely merged into [...]",

Messages that I marked as 'D' shouldn't ever be shown to an end-user
as they represent a Tcl error from incorrect usage of an internal
function.  Translating these is fine but since it should never
appear unless there is a serious bug in git-gui its probably not
worth the translation effort.

Messages marked as 'R' appear in the reflog for the corresponding
branch, etc.  These are not currently translated by core Git so I
am not sure if we should translate them in git-gui.

Messages marked as 'T' above are most definately shown to
the end-user and should be translated, or at least offered for
translation.  I realize some terms have been kept in their English
form even after translation as there isn't a good way to translate
them into every language.

-- 
Shawn.

  parent reply	other threads:[~2007-09-02  1:43 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-09-01  4:29 git-gui i18n status? Shawn O. Pearce
2007-09-01 23:42 ` Johannes Schindelin
2007-09-02  1:00   ` Junio C Hamano
2007-09-02  1:42   ` Shawn O. Pearce [this message]
2007-09-02  2:24     ` Shawn O. Pearce
2007-09-02 12:20       ` Johannes Schindelin
2007-09-16 12:03         ` Christian Stimming
2007-09-17  3:20           ` Shawn O. Pearce
2007-09-17  9:04             ` Johannes Schindelin
2007-09-02 12:29     ` Johannes Schindelin
2007-09-02 14:17   ` Michele Ballabio
  -- strict thread matches above, loose matches on Subject: below --
2007-09-02 15:09 Michele Ballabio

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=20070902014242.GJ18160@spearce.org \
    --to=spearce@spearce.org \
    --cc=Johannes.Schindelin@gmx.de \
    --cc=barra_cuda@katamail.com \
    --cc=git@vger.kernel.org \
    --cc=gitster@pobox.com \
    --cc=hliusvaa@cc.hut.fi \
    --cc=irina.riesen@gmail.com \
    --cc=nanako3@bluebottle.com \
    --cc=paolo.ciarrocchi@gmail.com \
    --cc=stimming@tuhh.de \
    --cc=vmiklos@frugalware.org \
    --cc=xudong.guan@gmail.com \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.