On Sat, Apr 21, 2012 at 1:40 PM, Shaun McCance 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 that I
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
> >
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 mea
> [: 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 th
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 th
On Thu, Apr 19, 2012 at 1:49 AM, Shaun McCance 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
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.
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 wrote:
> > On Tue, 2012-04-17 at 13:07 +0200, Matej U
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.
>
> 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
jmatsuz...@src.gn
On Thu, Apr 19, 2012 at 12:45 AM, Ask Hjorth Larsen 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
>> 2
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 does
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 rewra
> [: 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
NO, :) I pull, update and push.
M!
On Tue, Apr 17, 2012 at 3:58 PM, Shaun McCance 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 directly f
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
> >
On Tue, 2012-04-17 at 09:25 +0200, bruno wrote:
> Le lundi 16 avril 2012 à 18:34 -0400, Shaun McCance a écrit :
> > This is the workflow that usually leads to these kinds of problems:
> >
> > 1) Get the file from git and copy it to some folder somewhere.
> > 2) Edit the file.
> > 3) Update your g
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 h
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 loca
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 (li
> [: 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
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 with
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 me
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 ot
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 OVERW
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 document
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
--
mailto:ak...@gmx.
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 g
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 reverted. I don't know
what everybody's workflow is, but probably som
29 matches
Mail list logo
