Le lundi 16 avril 2012 à 18:34 -0400, Shaun McCance a écrit :
On Mon, 2012-04-16 at 23:04 +0200, Bruno Brouard wrote:
Le lundi 16 avril 2012 à 22:14 +0200, Andre Klapper a écrit :
On Mon, 2012-04-16 at 21:01 +0200, Bruno Brouard wrote:
I am sorry, i don't understand what you mean. Is it
On Thu, 2012-04-19 at 13:34 +0200, Chusslove Illich wrote:
4) Due to workflow, we don't have a baseline commit to reference.
[...]
(4) is a serious problem. git is really smart, and has a number of merge
strategies that I can only describe as magic. But they don't work if you
bypass
On Sat, Apr 21, 2012 at 1:40 PM, Shaun McCance sha...@gnome.org wrote:
On Thu, 2012-04-19 at 13:34 +0200, Chusslove Illich wrote:
4) Due to workflow, we don't have a baseline commit to reference.
[...]
(4) is a serious problem. git is really smart, and has a number of merge
strategies
[: Shaun McCance :]
I'm pretty sure that distinction belongs to PNG files. :)
Unless you consider them entirely outside of the realm of Git :)
And if there aren't amazing PO diff tools out there, somebody needs to
write one.
I'm getting to your points below, but I must again remind of the
[: Shaun McCance :]
The answer is plainly yes, if you use version control correctly. PO files
might have some characteristics that make some things harder, but they're
not so special that they're outside the realm of git.
But PO files are the furthest outwards in the realm of Git (version
Hi all,
As Chusslove says, version control of PO is more difficult than that
of normal source files.
But there are tips on how to manage PO on VCS.
1. --no-wrap
2. --no-location
The above points are msgmerge's options. Msgmerge with --no-wrap does
not wrap texts. That gets rid of noise from
Hi
On Thu, 19 Apr 2012, Jiro Matsuzawa wrote:
Hi all,
As Chusslove says, version control of PO is more difficult than that
of normal source files.
But there are tips on how to manage PO on VCS.
1. --no-wrap
2. --no-location
The above points are msgmerge's options. Msgmerge with --no-wrap
On Thu, Apr 19, 2012 at 12:45 AM, Ask Hjorth Larsen asklar...@gmail.com wrote:
Hi
On Thu, 19 Apr 2012, Jiro Matsuzawa wrote:
Hi all,
As Chusslove says, version control of PO is more difficult than that
of normal source files.
But there are tips on how to manage PO on VCS.
1. --no-wrap
If you have a source tree, you can extract location info at any time
with msgmerge.
So, no-location is not a problem.
Oops, with msgmerge is not right.
In case gnome-user-docs, $ make repo generates po with locations.
--
Jiro Matsuzawa
E-mail:
jmatsuz...@gnome.org
On Wed, 2012-04-18 at 10:40 +0200, Chusslove Illich wrote:
[: Shaun McCance :]
The answer is plainly yes, if you use version control correctly. PO files
might have some characteristics that make some things harder, but they're
not so special that they're outside the realm of git.
But PO
OK, great. Then this was just a freak accident, and we can all go
back to being awesome.
--
Shaun
On Tue, 2012-04-17 at 20:59 +0200, Matej Urban wrote:
NO, :) I pull, update and push.
M!
On Tue, Apr 17, 2012 at 3:58 PM, Shaun McCance sha...@gnome.org wrote:
On Tue, 2012-04-17 at 13:07
On Thu, 2012-04-19 at 01:05 +0900, Jiro Matsuzawa wrote:
If you have a source tree, you can extract location info at any time
with msgmerge.
So, no-location is not a problem.
Oops, with msgmerge is not right.
In case gnome-user-docs, $ make repo generates po with locations.
Be careful
On Thu, Apr 19, 2012 at 1:49 AM, Shaun McCance sha...@gnome.org wrote:
On Thu, 2012-04-19 at 01:05 +0900, Jiro Matsuzawa wrote:
If you have a source tree, you can extract location info at any time
with msgmerge.
So, no-location is not a problem.
Oops, with msgmerge is not right.
In case
Hi
On Wed, 18 Apr 2012, Shaun McCance wrote:
On Wed, 2012-04-18 at 10:40 +0200, Chusslove Illich wrote:
[: Shaun McCance :]
The answer is plainly yes, if you use version control correctly. PO files
might have some characteristics that make some things harder, but they're
not so special that
Le lundi 16 avril 2012 à 18:34 -0400, Shaun McCance a écrit :
On Mon, 2012-04-16 at 23:04 +0200, Bruno Brouard wrote:
Le lundi 16 avril 2012 à 22:14 +0200, Andre Klapper a écrit :
On Mon, 2012-04-16 at 21:01 +0200, Bruno Brouard wrote:
I am sorry, i don't understand what you mean. Is it
Bruno,
Following the workflow under DL will solve this kind of problems,
since you don't have to deal directly with Git. Also, DL merges you
translations with the main POT file, dinamically generated from the
source code, so if a developer adds new strings to a module, PO file
will be updated
[: bruno :]
Translators, proofreaders and commiters do hopefully not have to be in
computer science domain. I am not a programmer and not used to git. If i
have to read the git manual before committing, it would be very
discouraging.
Source version control (with Git or any other tool) is
Op Ma, 2012-04-16 om 18:34 -0400 skryf Shaun McCance:
And I realize many translators are used to basically owning their own
po files and not having to worry about other people editing them. But
module maintainers have to be able to fix syntax errors. And until we
get better tool support (like
Hello,
following this debate I noticed Slovenian translation being used as an example.
In our local copy, that gets updated directly from POT file, these
errors do NOT exist! in the gnome-help file.
I have no idea how this happens, but I do remember correcting them before.
We always update local
On Tue, 2012-04-17 at 13:07 +0200, Matej Urban wrote:
Hello,
following this debate I noticed Slovenian translation being used as an
example.
In our local copy, that gets updated directly from POT file, these
errors do NOT exist! in the gnome-help file.
I have no idea how this happens,
On Tue, 2012-04-17 at 10:43 +0200, Chusslove Illich wrote:
[: bruno :]
Translators, proofreaders and commiters do hopefully not have to be in
computer science domain. I am not a programmer and not used to git. If i
have to read the git manual before committing, it would be very
NO, :) I pull, update and push.
M!
On Tue, Apr 17, 2012 at 3:58 PM, Shaun McCance sha...@gnome.org wrote:
On Tue, 2012-04-17 at 13:07 +0200, Matej Urban wrote:
Hello,
following this debate I noticed Slovenian translation being used as an
example.
In our local copy, that gets updated
Le lundi 16 avril 2012 à 14:25 -0400, Shaun McCance a écrit :
Hi,
Sometimes translators make markup mistakes in docs translations.
When it happens in modules I make releases from, I go ahead and
fix the mistakes when I can. I don't mind doing that.
But recently, my fixes have been getting
On Mon, 2012-04-16 at 21:01 +0200, Bruno Brouard wrote:
I am sorry, i don't understand what you mean. Is it possible to have an
example?
To put it into other words:
Shaun fixed something in Git, and the translators OVERWROTE the fix with
his/her next commit to Git.
andre
--
Hi Shaun,
I opened a bug in Gtranslator asking to create a plugin based on gtxml
[1], to check this kind of incrrect markups.
I know Nacho is working on it, but at this moment, it isn't fisnished.
I hope he can get it fully implemented, so Gtranslator will warn about
incorrect markpup in
Le lundi 16 avril 2012 à 22:14 +0200, Andre Klapper a écrit :
On Mon, 2012-04-16 at 21:01 +0200, Bruno Brouard wrote:
I am sorry, i don't understand what you mean. Is it possible to have an
example?
To put it into other words:
Shaun fixed something in Git, and the translators OVERWROTE
On Mon, 2012-04-16 at 23:04 +0200, Bruno Brouard wrote:
Le lundi 16 avril 2012 à 22:14 +0200, Andre Klapper a écrit :
On Mon, 2012-04-16 at 21:01 +0200, Bruno Brouard wrote:
I am sorry, i don't understand what you mean. Is it possible to have an
example?
To put it into other words:
27 matches
Mail list logo
