On Fri, 2009-07-10 at 15:07 +0800, KSChan wrote:
> Hi Simion,
>
> If this is the case, does "svn diff" help you?
> Let's say just before your vacation, the en-file is in revision 101.
> After you back to online, the en-file revision is in 105.
>
>
> You may issue "svn diff -r 101:105 en-file "and
Hi Simion,
On Fri, Jul 10, 2009 at 1:39 PM, Simion Onea wrote:
>
> For example let's say that I (as a translator) took a vacation for two
> weeks. During this time a file has been updated and committed four
> times. When I return the system indicates that the file has changed. But
> it is not eno
On Thu, 2009-07-09 at 22:35 +0100, G. T. Stresen-Reuter wrote:
> As Hannes asks in another email in this same thread, is knowing how
> far out of sync a translation is really a useful feature? Isn't it
> enough to know that something is no longer in sync?
In my opinion the issue is not about k
On Jul 9, 2009, at 7:18 PM, Niel Archer wrote:
Why is this a problem? SVN revision numbers are incremental as well.
I don't see the difference between tying a translation to CVS-123456
and SVN-123456?
I'm not particularly familiar with CVS (fortunately), so someone
please
correct me if I'm
On Jul 9, 2009, at 6:31 PM, Hannes Magnusson wrote:
Create an md5 hash on the version you are translating and use that to
"uniquely" identify it. If the EN version is modified by even a
single
space, the hash will change and you'll know the files are out of
sync. What
you won't know is just
> On Thu, Jul 9, 2009 at 1:59 PM, Niel wrote:
> > Hi
> >
> >> When a translator updates a translation (a file), they write which CVS
> >> Revision in EN it's synced to. So, later when the EN version is
> >> updated we then know that the translated is outdated. And all of our
> >> translation tools
On Thu, Jul 9, 2009 at 1:59 PM, Niel wrote:
> Hi
>
>> When a translator updates a translation (a file), they write which CVS
>> Revision in EN it's synced to. So, later when the EN version is
>> updated we then know that the translated is outdated. And all of our
>> translation tools rely on the in
Hi
> When a translator updates a translation (a file), they write which CVS
> Revision in EN it's synced to. So, later when the EN version is
> updated we then know that the translated is outdated. And all of our
> translation tools rely on the incremental nature of CVS revision
> numbers.
On Thu, Jul 9, 2009 at 15:19, G. T.
Stresen-Reuter wrote:
> On Jul 9, 2009, at 1:24 AM, Philip Olson wrote:
>
>>>
>>> How are CVS Revision numbers used today? The best feature of po is that
>>> translation text is marked as 'fuzzy' when the main text is changed. If we
>>> could do the same with our
On Jul 9, 2009, at 1:24 AM, Philip Olson wrote:
How are CVS Revision numbers used today? The best feature of po is
that translation text is marked as 'fuzzy' when the main text is
changed. If we could do the same with our docbook translation files
whenever the en file is committed then we
How are CVS Revision numbers used today? The best feature of po is
that translation text is marked as 'fuzzy' when the main text is
changed. If we could do the same with our docbook translation files
whenever the en file is committed then we have the same benefits
imo. I'm wondering if CV
> Our main problem is with translations because CVS Revision numbers are
> required today and used with translations to track/sync with EN. I was
> hoping the gettext/po effort would have gone smoother by now but it hasn't.
> So, I ask that people think about solutions for how we handle this, and
On Jul 8, 2009, at 9:34 AM, Anthony Bedford wrote:
On 8 Jul 2009, at 03:56, Philip Olson wrote:
Soon the entire PHP project will throw itself into the fire and
migrate from CVS to SVN. This will break many activities here but
the task of editing EN DocBook files likely won't change much,
On 8 Jul 2009, at 03:56, Philip Olson wrote:
Soon the entire PHP project will throw itself into the fire and
migrate from CVS to SVN. This will break many activities here but
the task of editing EN DocBook files likely won't change much,
except for the commands to checkout/commit.
Will o
On Jul 8, 2009, at 12:38 AM, Hannes Magnusson wrote:
On Wed, Jul 8, 2009 at 04:56, Philip Olson wrote:
Our main problem is with translations because CVS Revision numbers
are
required today and used with translations to track/sync with EN. I
was
hoping the gettext/po effort would have gone s
On Wed, Jul 8, 2009 at 04:56, Philip Olson wrote:
> Our main problem is with translations because CVS Revision numbers are
> required today and used with translations to track/sync with EN. I was
> hoping the gettext/po effort would have gone smoother by now but it hasn't.
> So, I ask that people
Hello everyone,
Soon the entire PHP project will throw itself into the fire and
migrate from CVS to SVN. This will break many activities here but the
task of editing EN DocBook files likely won't change much, except for
the commands to checkout/commit.
I'll be away July 9-13 but Hannes is
17 matches
Mail list logo
