problem po

classic Classic list List threaded Threaded
6 messages Options
Reply | Threaded
Open this post in threaded view
|

problem po

Benny Malengier
Jerome,

I see some problems in po directory.

1./ new file [hidden email] gives problems with svn:

$ svn info [hidden email]
svn: Try 'svn help' for more info
svn: Syntax error parsing revision 'latin.po'

Could you investigate? If @ is not allowed in svn filenames, we could
hack the Makefile.am install to convert eg _at_ in a po to the @
character.

2./several po file have wrong permissions (see ls -all output), they
are set to execute. po files should never be read files. So,
chmod -x ar.po ...
or something like that

Benny

------------------------------------------------------------------------------
This SF.Net email is sponsored by the Verizon Developer Community
Take advantage of Verizon's best-in-class app development support
A streamlined, 14 day to market process makes app distribution fast and easy
Join now and get one step closer to millions of Verizon customers
http://p.sf.net/sfu/verizon-dev2dev 
_______________________________________________
Gramps-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gramps-devel
Reply | Threaded
Open this post in threaded view
|

Re: problem po

jerome
Benny,


Currently, I just added files, which was out of gramps and never added
on SVN (Arabic and Serbian latin translations). They are not added on
install process. I also planned to merge some data (translations
strings) from branch to trunk, only locales which are more recents on
branche than on trunk.

> 1./ new file [hidden email] gives problems with svn:
>
> $ svn info [hidden email]
> svn: Try 'svn help' for more info
> svn: Syntax error parsing revision 'latin.po'
>
> Could you investigate? If @ is not allowed in svn filenames, we could
> hack the Makefile.am install to convert eg _at_ in a po to the @
> character.

Sorry, you are right this seems to be used by svn ! :-[

"In version 1.1, Subversion introduced a way for you to tell it exactly
which Main Street you meant. It's called the peg revision, and it is a
revision provided to Subversion for the sole purpose of identifying a
unique line of history. Because at most one versioned object may occupy
a path at any given time—or, more precisely, in any one revision—the
combination of a path and a peg revision is all that is needed to refer
to a specific line of history. Peg revisions are specified to the
Subversion command-line client using at syntax, so called because the
syntax involves appending an “at sign” (@) and the peg revision to the
end of the path with which the revision is associated."

"The peg revision algorithm
The Subversion command-line performs the peg revision algorithm any time
it needs to resolve possible ambiguities in the paths and revisions
provided to it. Here's an example of such an invocation:

$ svn command -r OPERATIVE-REV item@PEG-REV

If OPERATIVE-REV is older than PEG-REV, then the algorithm is as follows:

     * Locate item in the revision identified by PEG-REV. There can be
only one such object.
     * Trace the object's history backwards (through any possible
renames) to its ancestor in the revision OPERATIVE-REV.
     * Perform the requested action on that ancestor, wherever it is
located, or whatever its name might be or have been at that time.

But what if OPERATIVE-REV is younger than PEG-REV? Well, that adds some
complexity to the theoretical problem of locating the path in
OPERATIVE-REV, because the path's history could have forked multiple
times (thanks to copy operations) between PEG-REV and OPERATIVE-REV. And
that's not all—Subversion doesn't store enough information to
performantly trace an object's history forward, anyway. So the algorithm
is a little different:
     * Locate item in the revision identified by OPERATIVE-REV. There
can be only one such object.
     * Trace the object's history backwards (through any possible
renames) to its ancestor in the revision PEG-REV.
     * Verify that the object's location (path-wise) in PEG-REV is the
same as it is in OPERATIVE-REV. If that's the case, then at least the
two locations are known to be directly related, so perform the requested
action on the location in OPERATIVE-REV. Otherwise, relatedness was not
established, so error out with a loud complaint that no viable location
was found. (Someday, we expect that Subversion will be able to handle
this usage scenario with more flexibility and grace.)

Note that even when you don't explicitly supply a peg revision or
operative revision, they are still present. For your convenience, the
default peg revision is BASE for working copy items and HEAD for
repository URLs. And when no operative revision is provided, it defaults
to being the same revision as the peg revision."

http://svnbook.red-bean.com/en/1.4/svn.advanced.pegrevs.html

> 2./several po file have wrong permissions (see ls -all output), they
> are set to execute. po files should never be read files.

My bad !
Was copied from an external support, or mail.

> So,
> chmod -x ar.po ...
> or something like that

I did it on ar.po fr.po gramps.pot mk.po POTFILES.skip POTFILES.in sl.po
sq.po [hidden email], but I need to make a change on files for been able to
commit something and maybe the permissions too !

If I try this :

svn propset svn:executable OFF ar.po fr.po gramps.pot mk.po
POTFILES.skip POTFILES.in sl.po sq.po [hidden email]

only 4 files has been commited ...
http://gramps.svn.sourceforge.net/viewvc/gramps?view=rev&revision=14057
/should POTFILES.skip POTFILES.in be executable ?/

I need help, I do not know what should be done ?


Jérôme




Benny Malengier a écrit :

> Jerome,
>
> I see some problems in po directory.
>
> 1./ new file [hidden email] gives problems with svn:
>
> $ svn info [hidden email]
> svn: Try 'svn help' for more info
> svn: Syntax error parsing revision 'latin.po'
>
> Could you investigate? If @ is not allowed in svn filenames, we could
> hack the Makefile.am install to convert eg _at_ in a po to the @
> character.
>
> 2./several po file have wrong permissions (see ls -all output), they
> are set to execute. po files should never be read files. So,
> chmod -x ar.po ...
> or something like that
>
> Benny
>


------------------------------------------------------------------------------
This SF.Net email is sponsored by the Verizon Developer Community
Take advantage of Verizon's best-in-class app development support
A streamlined, 14 day to market process makes app distribution fast and easy
Join now and get one step closer to millions of Verizon customers
http://p.sf.net/sfu/verizon-dev2dev 
_______________________________________________
Gramps-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gramps-devel
Reply | Threaded
Open this post in threaded view
|

Re: problem po

jerome
I suppose this is fixed by using :

$ svn propdel svn:executable ar.po fr.po gramps.pot mk.po POTFILES.skip
POTFILES.in sl.po sq.po [hidden email]

http://gramps.svn.sourceforge.net/viewvc/gramps?view=rev&revision=14059

Thank you, seems I was not aware of this UNIX things.
Now, I will take care of this.


For (@) into the name. I do not know what is the correct name ?

Under my /usr/share/locale directory, I see "sr@Latn" and the "at sign"
is used for something else on SVN command-line !


Note, added files (ar.po and [hidden email]) are not added on futur tarball
or installed because references are not yet set on configure.in.

Like Turkish, Romanian, Esperanto, Gramps needs new translators for this
locales ... Nevertheless, common translation strings (pedigree, parent,
birth date, event, menu, reports) are mostly the same between first time
release and current trunk revision. And only availables strings are
compiled (.mo). So Gramps' interface should be still localized into
these locales.



Jérôme a écrit :

> Benny,
>
>
> Currently, I just added files, which was out of gramps and never added
> on SVN (Arabic and Serbian latin translations). They are not added on
> install process. I also planned to merge some data (translations
> strings) from branch to trunk, only locales which are more recents on
> branche than on trunk.
>
>> 1./ new file [hidden email] gives problems with svn:
>>
>> $ svn info [hidden email]
>> svn: Try 'svn help' for more info
>> svn: Syntax error parsing revision 'latin.po'
>>
>> Could you investigate? If @ is not allowed in svn filenames, we could
>> hack the Makefile.am install to convert eg _at_ in a po to the @
>> character.
>
> Sorry, you are right this seems to be used by svn ! :-[
>
> "In version 1.1, Subversion introduced a way for you to tell it exactly
> which Main Street you meant. It's called the peg revision, and it is a
> revision provided to Subversion for the sole purpose of identifying a
> unique line of history. Because at most one versioned object may occupy
> a path at any given time—or, more precisely, in any one revision—the
> combination of a path and a peg revision is all that is needed to refer
> to a specific line of history. Peg revisions are specified to the
> Subversion command-line client using at syntax, so called because the
> syntax involves appending an “at sign” (@) and the peg revision to the
> end of the path with which the revision is associated."
>
> "The peg revision algorithm
> The Subversion command-line performs the peg revision algorithm any time
> it needs to resolve possible ambiguities in the paths and revisions
> provided to it. Here's an example of such an invocation:
>
> $ svn command -r OPERATIVE-REV item@PEG-REV
>
> If OPERATIVE-REV is older than PEG-REV, then the algorithm is as follows:
>
>      * Locate item in the revision identified by PEG-REV. There can be
> only one such object.
>      * Trace the object's history backwards (through any possible
> renames) to its ancestor in the revision OPERATIVE-REV.
>      * Perform the requested action on that ancestor, wherever it is
> located, or whatever its name might be or have been at that time.
>
> But what if OPERATIVE-REV is younger than PEG-REV? Well, that adds some
> complexity to the theoretical problem of locating the path in
> OPERATIVE-REV, because the path's history could have forked multiple
> times (thanks to copy operations) between PEG-REV and OPERATIVE-REV. And
> that's not all—Subversion doesn't store enough information to
> performantly trace an object's history forward, anyway. So the algorithm
> is a little different:
>      * Locate item in the revision identified by OPERATIVE-REV. There
> can be only one such object.
>      * Trace the object's history backwards (through any possible
> renames) to its ancestor in the revision PEG-REV.
>      * Verify that the object's location (path-wise) in PEG-REV is the
> same as it is in OPERATIVE-REV. If that's the case, then at least the
> two locations are known to be directly related, so perform the requested
> action on the location in OPERATIVE-REV. Otherwise, relatedness was not
> established, so error out with a loud complaint that no viable location
> was found. (Someday, we expect that Subversion will be able to handle
> this usage scenario with more flexibility and grace.)
>
> Note that even when you don't explicitly supply a peg revision or
> operative revision, they are still present. For your convenience, the
> default peg revision is BASE for working copy items and HEAD for
> repository URLs. And when no operative revision is provided, it defaults
> to being the same revision as the peg revision."
>
> http://svnbook.red-bean.com/en/1.4/svn.advanced.pegrevs.html
>
>> 2./several po file have wrong permissions (see ls -all output), they
>> are set to execute. po files should never be read files.
>
> My bad !
> Was copied from an external support, or mail.
>
>> So,
>> chmod -x ar.po ...
>> or something like that
>
> I did it on ar.po fr.po gramps.pot mk.po POTFILES.skip POTFILES.in sl.po
> sq.po [hidden email], but I need to make a change on files for been able to
> commit something and maybe the permissions too !
>
> If I try this :
>
> svn propset svn:executable OFF ar.po fr.po gramps.pot mk.po
> POTFILES.skip POTFILES.in sl.po sq.po [hidden email]
>
> only 4 files has been commited ...
> http://gramps.svn.sourceforge.net/viewvc/gramps?view=rev&revision=14057
> /should POTFILES.skip POTFILES.in be executable ?/
>
> I need help, I do not know what should be done ?
>
>
> Jérôme
>
>
>
>
> Benny Malengier a écrit :
>> Jerome,
>>
>> I see some problems in po directory.
>>
>> 1./ new file [hidden email] gives problems with svn:
>>
>> $ svn info [hidden email]
>> svn: Try 'svn help' for more info
>> svn: Syntax error parsing revision 'latin.po'
>>
>> Could you investigate? If @ is not allowed in svn filenames, we could
>> hack the Makefile.am install to convert eg _at_ in a po to the @
>> character.
>>
>> 2./several po file have wrong permissions (see ls -all output), they
>> are set to execute. po files should never be read files. So,
>> chmod -x ar.po ...
>> or something like that
>>
>> Benny
>>
>
>
> ------------------------------------------------------------------------------
> This SF.Net email is sponsored by the Verizon Developer Community
> Take advantage of Verizon's best-in-class app development support
> A streamlined, 14 day to market process makes app distribution fast and easy
> Join now and get one step closer to millions of Verizon customers
> http://p.sf.net/sfu/verizon-dev2dev 
> _______________________________________________
> Gramps-devel mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/gramps-devel


------------------------------------------------------------------------------
This SF.Net email is sponsored by the Verizon Developer Community
Take advantage of Verizon's best-in-class app development support
A streamlined, 14 day to market process makes app distribution fast and easy
Join now and get one step closer to millions of Verizon customers
http://p.sf.net/sfu/verizon-dev2dev 
_______________________________________________
Gramps-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gramps-devel
Reply | Threaded
Open this post in threaded view
|

Re: problem po

Benny Malengier
2010/1/13 Jérôme <[hidden email]>:
> I suppose this is fixed by using :
>
> $ svn propdel svn:executable ar.po fr.po gramps.pot mk.po POTFILES.skip
> POTFILES.in sl.po sq.po [hidden email]

what is the directory in LC_MESSAGES? Is it really
/[hidden email]/LC_MESSAGES/gramps.mo ?

Benny

>
> http://gramps.svn.sourceforge.net/viewvc/gramps?view=rev&revision=14059
>
> Thank you, seems I was not aware of this UNIX things.
> Now, I will take care of this.
>
>
> For (@) into the name. I do not know what is the correct name ?
>
> Under my /usr/share/locale directory, I see "sr@Latn" and the "at sign" is
> used for something else on SVN command-line !
>
>
> Note, added files (ar.po and [hidden email]) are not added on futur tarball or
> installed because references are not yet set on configure.in.
>
> Like Turkish, Romanian, Esperanto, Gramps needs new translators for this
> locales ... Nevertheless, common translation strings (pedigree, parent,
> birth date, event, menu, reports) are mostly the same between first time
> release and current trunk revision. And only availables strings are compiled
> (.mo). So Gramps' interface should be still localized into these locales.
>
>
>
> Jérôme a écrit :
>>
>> Benny,
>>
>>
>> Currently, I just added files, which was out of gramps and never added on
>> SVN (Arabic and Serbian latin translations). They are not added on install
>> process. I also planned to merge some data (translations strings) from
>> branch to trunk, only locales which are more recents on branche than on
>> trunk.
>>
>>> 1./ new file [hidden email] gives problems with svn:
>>>
>>> $ svn info [hidden email]
>>> svn: Try 'svn help' for more info
>>> svn: Syntax error parsing revision 'latin.po'
>>>
>>> Could you investigate? If @ is not allowed in svn filenames, we could
>>> hack the Makefile.am install to convert eg _at_ in a po to the @
>>> character.
>>
>> Sorry, you are right this seems to be used by svn ! :-[
>>
>> "In version 1.1, Subversion introduced a way for you to tell it exactly
>> which Main Street you meant. It's called the peg revision, and it is a
>> revision provided to Subversion for the sole purpose of identifying a unique
>> line of history. Because at most one versioned object may occupy a path at
>> any given time—or, more precisely, in any one revision—the combination of a
>> path and a peg revision is all that is needed to refer to a specific line of
>> history. Peg revisions are specified to the Subversion command-line client
>> using at syntax, so called because the syntax involves appending an “at
>> sign” (@) and the peg revision to the end of the path with which the
>> revision is associated."
>>
>> "The peg revision algorithm
>> The Subversion command-line performs the peg revision algorithm any time
>> it needs to resolve possible ambiguities in the paths and revisions provided
>> to it. Here's an example of such an invocation:
>>
>> $ svn command -r OPERATIVE-REV item@PEG-REV
>>
>> If OPERATIVE-REV is older than PEG-REV, then the algorithm is as follows:
>>
>>     * Locate item in the revision identified by PEG-REV. There can be only
>> one such object.
>>     * Trace the object's history backwards (through any possible renames)
>> to its ancestor in the revision OPERATIVE-REV.
>>     * Perform the requested action on that ancestor, wherever it is
>> located, or whatever its name might be or have been at that time.
>>
>> But what if OPERATIVE-REV is younger than PEG-REV? Well, that adds some
>> complexity to the theoretical problem of locating the path in OPERATIVE-REV,
>> because the path's history could have forked multiple times (thanks to copy
>> operations) between PEG-REV and OPERATIVE-REV. And that's not all—Subversion
>> doesn't store enough information to performantly trace an object's history
>> forward, anyway. So the algorithm is a little different:
>>     * Locate item in the revision identified by OPERATIVE-REV. There can
>> be only one such object.
>>     * Trace the object's history backwards (through any possible renames)
>> to its ancestor in the revision PEG-REV.
>>     * Verify that the object's location (path-wise) in PEG-REV is the same
>> as it is in OPERATIVE-REV. If that's the case, then at least the two
>> locations are known to be directly related, so perform the requested action
>> on the location in OPERATIVE-REV. Otherwise, relatedness was not
>> established, so error out with a loud complaint that no viable location was
>> found. (Someday, we expect that Subversion will be able to handle this usage
>> scenario with more flexibility and grace.)
>>
>> Note that even when you don't explicitly supply a peg revision or
>> operative revision, they are still present. For your convenience, the
>> default peg revision is BASE for working copy items and HEAD for repository
>> URLs. And when no operative revision is provided, it defaults to being the
>> same revision as the peg revision."
>>
>> http://svnbook.red-bean.com/en/1.4/svn.advanced.pegrevs.html
>>
>>> 2./several po file have wrong permissions (see ls -all output), they
>>> are set to execute. po files should never be read files.
>>
>> My bad !
>> Was copied from an external support, or mail.
>>
>>> So,
>>> chmod -x ar.po ...
>>> or something like that
>>
>> I did it on ar.po fr.po gramps.pot mk.po POTFILES.skip POTFILES.in sl.po
>> sq.po [hidden email], but I need to make a change on files for been able to
>> commit something and maybe the permissions too !
>>
>> If I try this :
>>
>> svn propset svn:executable OFF ar.po fr.po gramps.pot mk.po POTFILES.skip
>> POTFILES.in sl.po sq.po [hidden email]
>>
>> only 4 files has been commited ...
>> http://gramps.svn.sourceforge.net/viewvc/gramps?view=rev&revision=14057
>> /should POTFILES.skip POTFILES.in be executable ?/
>>
>> I need help, I do not know what should be done ?
>>
>>
>> Jérôme
>>
>>
>>
>>
>> Benny Malengier a écrit :
>>>
>>> Jerome,
>>>
>>> I see some problems in po directory.
>>>
>>> 1./ new file [hidden email] gives problems with svn:
>>>
>>> $ svn info [hidden email]
>>> svn: Try 'svn help' for more info
>>> svn: Syntax error parsing revision 'latin.po'
>>>
>>> Could you investigate? If @ is not allowed in svn filenames, we could
>>> hack the Makefile.am install to convert eg _at_ in a po to the @
>>> character.
>>>
>>> 2./several po file have wrong permissions (see ls -all output), they
>>> are set to execute. po files should never be read files. So,
>>> chmod -x ar.po ...
>>> or something like that
>>>
>>> Benny
>>>
>>
>>
>>
>> ------------------------------------------------------------------------------
>> This SF.Net email is sponsored by the Verizon Developer Community
>> Take advantage of Verizon's best-in-class app development support
>> A streamlined, 14 day to market process makes app distribution fast and
>> easy
>> Join now and get one step closer to millions of Verizon customers
>> http://p.sf.net/sfu/verizon-dev2dev
>> _______________________________________________
>> Gramps-devel mailing list
>> [hidden email]
>> https://lists.sourceforge.net/lists/listinfo/gramps-devel
>
>

------------------------------------------------------------------------------
This SF.Net email is sponsored by the Verizon Developer Community
Take advantage of Verizon's best-in-class app development support
A streamlined, 14 day to market process makes app distribution fast and easy
Join now and get one step closer to millions of Verizon customers
http://p.sf.net/sfu/verizon-dev2dev 
_______________________________________________
Gramps-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gramps-devel
Reply | Threaded
Open this post in threaded view
|

Re: problem po

jerome
I do not know what is the difference between sr@latin
http://www.debian.org/international/l10n/po/sr@latin
and sr@Latn
http://www.debian.org/international/l10n/po/sr@Latn

It looks like sr@latin is used on last GNOME versions
http://l10n.gnome.org/teams/sr@latin
vs
http://l10n.gnome.org/teams/sr@Latn

But Ubuntu uses sr@Latn !!!
http://packages.ubunut.com/en/lucid/all/kde-i18n-srlatn/filelist

> what is the directory in LC_MESSAGES? Is it really
> /[hidden email]/LC_MESSAGES/gramps.mo

under Ubuntu 8.04, it is /sr@Latn/LC_MESSAGES/ ...

I suppose python will look at iso_639_1_code="sr", but true, there is a distribution issue : where to install Serbian (latin) translation ?

Vlada provided a partial Serbian (latin) translation for Gramps-3.0.x. http://www.gramps-project.org/bugs/view.php?id=2375
and he also needs to print reports easier.

If there is limitations on current way to handle translations, this could be fixed but there is not a lot of return on current Hebrew or Arabic management (right to left) or complex locales (plural forms, gender prefix/suffix, genetive, etc ...).
To have an up to date translation file somewhere is for keeping this primary work alive !

Vlada,

Maybe we can just use sr.po ?



--- En date de : Mer 13.1.10, Benny Malengier <[hidden email]> a écrit :

> De: Benny Malengier <[hidden email]>
> Objet: Re: [Gramps-devel] problem po
> À: [hidden email]
> Cc: "Gramps Development List" <[hidden email]>, "Vlada Peric" <[hidden email]>
> Date: Mercredi 13 Janvier 2010, 12h44
> 2010/1/13 Jérôme <[hidden email]>:
> > I suppose this is fixed by using :
> >
> > $ svn propdel svn:executable ar.po fr.po gramps.pot
> mk.po POTFILES.skip
> > POTFILES.in sl.po sq.po [hidden email]
>
> what is the directory in LC_MESSAGES? Is it really
> /[hidden email]/LC_MESSAGES/gramps.mo
> ?
>
> Benny
> >
> > http://gramps.svn.sourceforge.net/viewvc/gramps?view=rev&revision=14059
> >
> > Thank you, seems I was not aware of this UNIX things.
> > Now, I will take care of this.
> >
> >
> > For (@) into the name. I do not know what is the
> correct name ?
> >
> > Under my /usr/share/locale directory, I see "sr@Latn"
> and the "at sign" is
> > used for something else on SVN command-line !
> >
> >
> > Note, added files (ar.po and [hidden email]) are not
> added on futur tarball or
> > installed because references are not yet set on
> configure.in.
> >
> > Like Turkish, Romanian, Esperanto, Gramps needs new
> translators for this
> > locales ... Nevertheless, common translation strings
> (pedigree, parent,
> > birth date, event, menu, reports) are mostly the same
> between first time
> > release and current trunk revision. And only
> availables strings are compiled
> > (.mo). So Gramps' interface should be still localized
> into these locales.
> >
> >
> >
> > Jérôme a écrit :
> >>
> >> Benny,
> >>
> >>
> >> Currently, I just added files, which was out of
> gramps and never added on
> >> SVN (Arabic and Serbian latin translations). They
> are not added on install
> >> process. I also planned to merge some data
> (translations strings) from
> >> branch to trunk, only locales which are more
> recents on branche than on
> >> trunk.
> >>
> >>> 1./ new file [hidden email] gives
> problems with svn:
> >>>
> >>> $ svn info [hidden email]
> >>> svn: Try 'svn help' for more info
> >>> svn: Syntax error parsing revision 'latin.po'
> >>>
> >>> Could you investigate? If @ is not allowed in
> svn filenames, we could
> >>> hack the Makefile.am install to convert eg
> _at_ in a po to the @
> >>> character.
> >>
> >> Sorry, you are right this seems to be used by svn
> ! :-[
> >>
> >> "In version 1.1, Subversion introduced a way for
> you to tell it exactly
> >> which Main Street you meant. It's called the peg
> revision, and it is a
> >> revision provided to Subversion for the sole
> purpose of identifying a unique
> >> line of history. Because at most one versioned
> object may occupy a path at
> >> any given time—or, more precisely, in any one
> revision—the combination of a
> >> path and a peg revision is all that is needed to
> refer to a specific line of
> >> history. Peg revisions are specified to the
> Subversion command-line client
> >> using at syntax, so called because the syntax
> involves appending an “at
> >> sign” (@) and the peg revision to the end of the
> path with which the
> >> revision is associated."
> >>
> >> "The peg revision algorithm
> >> The Subversion command-line performs the peg
> revision algorithm any time
> >> it needs to resolve possible ambiguities in the
> paths and revisions provided
> >> to it. Here's an example of such an invocation:
> >>
> >> $ svn command -r OPERATIVE-REV item@PEG-REV
> >>
> >> If OPERATIVE-REV is older than PEG-REV, then the
> algorithm is as follows:
> >>
> >>     * Locate item in the revision identified by
> PEG-REV. There can be only
> >> one such object.
> >>     * Trace the object's history backwards
> (through any possible renames)
> >> to its ancestor in the revision OPERATIVE-REV.
> >>     * Perform the requested action on that
> ancestor, wherever it is
> >> located, or whatever its name might be or have
> been at that time.
> >>
> >> But what if OPERATIVE-REV is younger than PEG-REV?
> Well, that adds some
> >> complexity to the theoretical problem of locating
> the path in OPERATIVE-REV,
> >> because the path's history could have forked
> multiple times (thanks to copy
> >> operations) between PEG-REV and OPERATIVE-REV. And
> that's not all—Subversion
> >> doesn't store enough information to performantly
> trace an object's history
> >> forward, anyway. So the algorithm is a little
> different:
> >>     * Locate item in the revision identified by
> OPERATIVE-REV. There can
> >> be only one such object.
> >>     * Trace the object's history backwards
> (through any possible renames)
> >> to its ancestor in the revision PEG-REV.
> >>     * Verify that the object's location
> (path-wise) in PEG-REV is the same
> >> as it is in OPERATIVE-REV. If that's the case,
> then at least the two
> >> locations are known to be directly related, so
> perform the requested action
> >> on the location in OPERATIVE-REV. Otherwise,
> relatedness was not
> >> established, so error out with a loud complaint
> that no viable location was
> >> found. (Someday, we expect that Subversion will be
> able to handle this usage
> >> scenario with more flexibility and grace.)
> >>
> >> Note that even when you don't explicitly supply a
> peg revision or
> >> operative revision, they are still present. For
> your convenience, the
> >> default peg revision is BASE for working copy
> items and HEAD for repository
> >> URLs. And when no operative revision is provided,
> it defaults to being the
> >> same revision as the peg revision."
> >>
> >> http://svnbook.red-bean.com/en/1.4/svn.advanced.pegrevs.html
> >>
> >>> 2./several po file have wrong permissions (see
> ls -all output), they
> >>> are set to execute. po files should never be
> read files.
> >>
> >> My bad !
> >> Was copied from an external support, or mail.
> >>
> >>> So,
> >>> chmod -x ar.po ...
> >>> or something like that
> >>
> >> I did it on ar.po fr.po gramps.pot mk.po
> POTFILES.skip POTFILES.in sl.po
> >> sq.po [hidden email], but I
> need to make a change on files for been able to
> >> commit something and maybe the permissions too !
> >>
> >> If I try this :
> >>
> >> svn propset svn:executable OFF ar.po fr.po
> gramps.pot mk.po POTFILES.skip
> >> POTFILES.in sl.po sq.po [hidden email]
> >>
> >> only 4 files has been commited ...
> >> http://gramps.svn.sourceforge.net/viewvc/gramps?view=rev&revision=14057
> >> /should POTFILES.skip POTFILES.in be executable
> ?/
> >>
> >> I need help, I do not know what should be done ?
> >>
> >>
> >> Jérôme
> >>
> >>
> >>
> >>
> >> Benny Malengier a écrit :
> >>>
> >>> Jerome,
> >>>
> >>> I see some problems in po directory.
> >>>
> >>> 1./ new file [hidden email] gives
> problems with svn:
> >>>
> >>> $ svn info [hidden email]
> >>> svn: Try 'svn help' for more info
> >>> svn: Syntax error parsing revision 'latin.po'
> >>>
> >>> Could you investigate? If @ is not allowed in
> svn filenames, we could
> >>> hack the Makefile.am install to convert eg
> _at_ in a po to the @
> >>> character.
> >>>
> >>> 2./several po file have wrong permissions (see
> ls -all output), they
> >>> are set to execute. po files should never be
> read files. So,
> >>> chmod -x ar.po ...
> >>> or something like that
> >>>
> >>> Benny
> >>>
> >>
> >>
> >>
> >>
> ------------------------------------------------------------------------------
> >> This SF.Net email is sponsored by the Verizon
> Developer Community
> >> Take advantage of Verizon's best-in-class app
> development support
> >> A streamlined, 14 day to market process makes app
> distribution fast and
> >> easy
> >> Join now and get one step closer to millions of
> Verizon customers
> >> http://p.sf.net/sfu/verizon-dev2dev
> >> _______________________________________________
> >> Gramps-devel mailing list
> >> [hidden email]
> >> https://lists.sourceforge.net/lists/listinfo/gramps-devel
> >
> >
>


     

------------------------------------------------------------------------------
This SF.Net email is sponsored by the Verizon Developer Community
Take advantage of Verizon's best-in-class app development support
A streamlined, 14 day to market process makes app distribution fast and easy
Join now and get one step closer to millions of Verizon customers
http://p.sf.net/sfu/verizon-dev2dev 
_______________________________________________
Gramps-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gramps-devel
Reply | Threaded
Open this post in threaded view
|

Re: problem po

Vladimir Perić
Vlada,

Maybe we can just use sr.po ?

Yes, that would be fine; also consider the following bug submitted against Python itself (Python can't even parse the @latin as part of a locale name):

http://bugs.python.org/issue6668

As for @latin vs. @Latn, I believe the former is more used now. My Ubuntu has both a @Latn and @latin directory, but there's more entries in the first.

--
Vlada Perić

------------------------------------------------------------------------------
This SF.Net email is sponsored by the Verizon Developer Community
Take advantage of Verizon's best-in-class app development support
A streamlined, 14 day to market process makes app distribution fast and easy
Join now and get one step closer to millions of Verizon customers
http://p.sf.net/sfu/verizon-dev2dev 
_______________________________________________
Gramps-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gramps-devel