Re: es.po and small bug fix

[Jean-Marc Lasgouttes]

 "Lars" == Lars Gullik Bjønnes [EMAIL PROTECTED] writes:

Lars 3. means to extract the needed informatin from the babel
Lars .ldf files. This not be too hard and using the substring and the
Lars regex class form the old 1.1.x series should help a lot.

It would not be too difficult to write a LaTeX script which inputs
.ldf files and spits out datafiles for LyX. We could either do it just
once and distribute the datafiles or do it at configure time (is that
useful?). 

The real problem I see is accents: in portugues.ldf, we have
 \def\refname{Refer\^encias}

What shall we do about that? The first idea is to translate to latin1
(with recode, for example). However, for some languages, latin2 (or
another one) would be a better choice.

So maybe creating the data files once in a semi automatic way will be
the best choice...

JMarc

Re: es.po and small bug fix

[Jean-Marc Lasgouttes]

 "Lars" == Lars Gullik Bjønnes [EMAIL PROTECTED] writes:

Lars Note that we only care about the default menus, user modified
Lars menus we can do nothing about. What do you mean by "hardcode
Lars translations"? We will add the menu definitions file to the list
Lars of files gettext scans for localization strings.

I mean that a user cannot, for example, put his own translation of
menus in his local directory and have LyX use it. I personally think
that this feature of being able to modify LyX behaviour at user level
is a very nice one.

JMarc

Re: es.po and small bug fix

[Lars Gullik Bjønnes]

Jean-Marc Lasgouttes [EMAIL PROTECTED] writes:

| I mean that a user cannot, for example, put his own translation of
| menus in his local directory and have LyX use it.

Why not?

| I personally think
| that this feature of being able to modify LyX behaviour at user level
| is a very nice one.

Agree.

Lgb

Re: es.po and small bug fix

[Lars Gullik Bjønnes]

Jean-Marc Lasgouttes [EMAIL PROTECTED] writes:

|  "Lars" == Lars Gullik Bjønnes [EMAIL PROTECTED] writes:
| 
| Lars 3. means to extract the needed informatin from the babel
| Lars .ldf files. This not be too hard and using the substring and the
| Lars regex class form the old 1.1.x series should help a lot.
| 
| It would not be too difficult to write a LaTeX script which inputs
| .ldf files and spits out datafiles for LyX. We could either do it just
| once and distribute the datafiles or do it at configure time (is that
| useful?). 

We have three options on when to extract language strings from the
.ldf files:
1. static (we extract and distribute with lyx)
2. at configure time.
3. live from a running LyX.

These are no listed in my reverse prefered order.
If we could have a nice automatic-interface to 3. that would imho be
nicest, 2. is also almost equally nice and 1. should not be considered
at all.

| The real problem I see is accents: in portugues.ldf, we have
|  \def\refname{Refer\^encias}

Does \^ have special meaning in portugues? Or is it the regular accent
that insetlatexaccent is able to handle?

| What shall we do about that? The first idea is to translate to latin1
| (with recode, for example). However, for some languages, latin2 (or
| another one) would be a better choice.

I think we can solve this. AFAIK 8bit chars are not used in .ldf files
only (La)TeX accent commands, and we can handle those. 

| So maybe creating the data files once in a semi automatic way will be
| the best choice...

Fully automatic please...

Lgb

Re: es.po and small bug fix

[Jean-Marc Lasgouttes]

 "Lars" == Lars Gullik Bjønnes [EMAIL PROTECTED] writes:

Lars We have three options on when to extract language strings from
Lars the .ldf files: 1. static (we extract and distribute with lyx)
Lars 2. at configure time. 3. live from a running LyX.

Lars These are no listed in my reverse prefered order. If we could
Lars have a nice automatic-interface to 3. that would imho be nicest,
Lars 2. is also almost equally nice and 1. should not be considered
Lars at all.

I think 2 is the simplest, since having latex do the parsing is safer.

Lars Does \^ have special meaning in portugues? Or is it the regular
Lars accent that insetlatexaccent is able to handle?

So, what about:
  \def\refname{%
{\cyr \CYRS\CYRp\CYRi\CYRs\CYRo\CYRk\space
  \CYRl\CYRi\CYRt\CYRe\CYRr\CYRa\CYRt\CYRu\CYRr\CYRy}}%

[I'll let you guess where this one came from]

JMarc

Re: es.po and small bug fix

[Jose Abilio Oliveira Matos]

On Wed, Oct 13, 1999 at 01:45:50PM +0200, Lars Gullik Bjønnes wrote:
 
 | The real problem I see is accents: in portugues.ldf, we have
 |  \def\refname{Refer\^encias}
 
 Does \^ have special meaning in portugues? Or is it the regular accent
 that insetlatexaccent is able to handle?
 
  The later. \^e is ê
 
   Lgb

  For docbook and linuxdoc maybe we could use the latex translation, where
available.

-- 
José

Re: es.po and small bug fix

[Lars Gullik Bjønnes]

Jose Abilio Oliveira Matos [EMAIL PROTECTED] writes:

| On Wed, Oct 13, 1999 at 01:45:50PM +0200, Lars Gullik Bjønnes wrote:
|  
|  | The real problem I see is accents: in portugues.ldf, we have
|  |  \def\refname{Refer\^encias}
|  
|  Does \^ have special meaning in portugues? Or is it the regular accent
|  that insetlatexaccent is able to handle?
|  
|   The later. \^e is ê

Ok, then we already have the functions to parse and extract this.

|   For docbook and linuxdoc maybe we could use the latex translation, where
| available.

Yes, why not.

Lgb

Re: es.po and small bug fix

[Jean-Marc Lasgouttes]

 "Lars" == Lars Gullik Bjønnes [EMAIL PROTECTED] writes:

Lars Jean-Marc Lasgouttes [EMAIL PROTECTED] writes: | I
Lars mean that a user cannot, for example, put his own translation of
Lars | menus in his local directory and have LyX use it.

Lars Why not?

Because po files cannot be used like that. They are hardcoded to live
in /foo/share/locale/... So people who do not have root access and
want to develop their own translation cannot do that easily. Also, I
think it would be good to be able to distribute a msword menu layout
(complete with french translation, because I am french and I can do
it) and that people are able to use it without patching lyx. That's
what people can do now when adding a new textclass, and I think it is good.

And what about bind files translation? Do you plan to use gettext too? 

The idea I had is the following: we could separate all language
specific stuff in their own archive, like

lib/layout/fr_stdsections.inc
...
lib/doc/fr_Intro.lyx
...
lib/ui/fr_default.ui  (this is something I'd like to introduce later
   to define both menus and toolbars)
lib/bind/fr_cua.bind
po/fr.po  (not sure about this one)

This way, each translation team would be responsible for managing
*all* translations on their own.

Then one could do
tar zxvf lyx-1.1.2.tar.gz
cd lyx-1.1.2
tar zxvf lyx-fr-1.1.2.tar.gz (I think we should not have a lyx-1.1.2
  prefix in the i18n tar files so that
  they needn't be updated at each version) 
./configure
make

Instead of using this fr_ convention on files, we could also put
everything in a different directory (lib/fr/...).

The problem I see with using gettext everywhere is that we have to
resolve ambiguities; I do not know whether they exist right now, but I
am sure we will eventually come to cases where we want different
translations for a given string, and the solution will necessarily be
ugly. This is the major gettext limitation as far as I am concerned.

JMarc

Re: es.po and small bug fix

[Lars Gullik Bjønnes]

Jean-Marc Lasgouttes [EMAIL PROTECTED] writes:

|  "Lars" == Lars Gullik Bjønnes [EMAIL PROTECTED] writes:
| 
| Lars We have three options on when to extract language strings from
| Lars the .ldf files: 1. static (we extract and distribute with lyx)
| Lars 2. at configure time. 3. live from a running LyX.
| 
| Lars These are no listed in my reverse prefered order. If we could
| Lars have a nice automatic-interface to 3. that would imho be nicest,
| Lars 2. is also almost equally nice and 1. should not be considered
| Lars at all.
| 
| I think 2 is the simplest, since having latex do the parsing is safer.
| 
| Lars Does \^ have special meaning in portugues? Or is it the regular
| Lars accent that insetlatexaccent is able to handle?
| 
| So, what about:
|   \def\refname{%
| {\cyr \CYRS\CYRp\CYRi\CYRs\CYRo\CYRk\space
|   \CYRl\CYRi\CYRt\CYRe\CYRr\CYRa\CYRt\CYRu\CYRr\CYRy}}%

We just need a module that knows how to display cyrillic, a lot of
these problems will go away/be easier to solve when/if we switch to
unicode.

I am beginning to leand towards using unicode internally in LyX all
the time.

Lgb

Re: es.po and small bug fix

[Lars Gullik Bjønnes]

Jean-Marc Lasgouttes [EMAIL PROTECTED] writes:

|  "Lars" == Lars Gullik Bjønnes [EMAIL PROTECTED] writes:
| 
| Lars We have three options on when to extract language strings from
| Lars the .ldf files: 1. static (we extract and distribute with lyx)
| Lars 2. at configure time. 3. live from a running LyX.
| 
| Lars These are no listed in my reverse prefered order. If we could
| Lars have a nice automatic-interface to 3. that would imho be nicest,
| Lars 2. is also almost equally nice and 1. should not be considered
| Lars at all.
| 
| I think 2 is the simplest, since having latex do the parsing is safer.
| 
| Lars Does \^ have special meaning in portugues? Or is it the regular
| Lars accent that insetlatexaccent is able to handle?
| 
| So, what about:
|   \def\refname{%
| {\cyr \CYRS\CYRp\CYRi\CYRs\CYRo\CYRk\space
|   \CYRl\CYRi\CYRt\CYRe\CYRr\CYRa\CYRt\CYRu\CYRr\CYRy}}%

+ addition to prev mail:

I don't think it would be so bad of us to focus mainly on latin
charsets for the timebeeing. We could also consider moving to using
unicode internally fairly quick.

Lgb

Re: es.po and small bug fix

[Jean-Marc Lasgouttes]

 "Lars" == Lars Gullik Bjønnes [EMAIL PROTECTED] writes:

Lars We just need a module that knows how to display cyrillic, a lot
Lars of these problems will go away/be easier to solve when/if we
Lars switch to unicode.

Lars I am beginning to leand towards using unicode internally in LyX
Lars all the time.

I agree, but this a long-term solution. The short-term solution I was
thinking about was to create (partly) by hand a configuration file
which has the strings in the encoding corresponding to the language.
When we have uncode and eveything it will be able to plug in without
much work the clean solution.

JMarc

Re: es.po and small bug fix

[Asger K. Alstrup Nielsen]

 Fully automatic please...

One note though:

Fully automatic seems best, but it is also the most risky. We do not have
control over which strange LaTeX installatinopneople have, and therefore
we would need to build a robust system if it has to work on everything
out there.

I think that a static system is fully adequate. It's not like these strings 
are changing every day.  Actually, I don't think they change at all once
they are done...

I think we should adopt a development model where we reduce risks.
That implies chosing the simple solutions sometimes.

Greets,

Asger

Re: es.po and small bug fix

[Lars Gullik Bjønnes]

"Asger K. Alstrup Nielsen" [EMAIL PROTECTED] writes:

|  Fully automatic please...
| 
| One note though:
| 
| Fully automatic seems best, but it is also the most risky. We do not have
| control over which strange LaTeX installatinopneople have, and therefore
| we would need to build a robust system if it has to work on everything
| out there.

That is impossible anyway...

| I think that a static system is fully adequate. It's not like these strings 
| are changing every day.  Actually, I don't think they change at all once
| they are done...

We should have a automatic way of updating these files anyway...
And it is to me a bit bad to supply 20+ languages with lyx.

Ok...what about this:

We supply scripts/code to do the extraction of language strings from
.ldf on install time. We also provide as a _separate_ package a
collection of language definition files. And of course we will always
supply the default/hardcoded strings.

| I think we should adopt a development model where we reduce risks.
| That implies chosing the simple solutions sometimes.

Sure...

Lgb

Re: es.po and small bug fix

[miyata]

"Asger K. Alstrup Nielsen" [EMAIL PROTECTED] wrote:

  - muddle on with gettext

 This is the least intrusive solution, and thus the safest one.

Do you mean something like:

/* FileGetText: This is C. */
/* Use it as
   #define __(str) fgettext(\
 LibFileSearch(\
 "layout_messages", \
 current_view-currentBuffer()-params.language, \
 "mo").c_str(), \
 str)
*/
#include sys/types.h
#include "gettext.h"
#include "gettextP.h"

extern char *find_msg(struct loaded_l10nfile *domain_file, const char *msgid);

char *fgettext(char *fullpath_to_msgobj, const char *msgid)
{
struct loaded_l10nfile *domain_file;
char *retval;

domain_file-filename = fullpath_to_msgobj;
_nl_load_domain (domain_file);
retval = find_msg (domain_file, msgid);

return retval ? retval : msgid;
}


?
The obvious problem with this approach is that we have to link GNU
version of libintl.  But if we are going to adopt this, then the
rest is to write a script to extract .po files from .ldf files.

Regards,
SMiyata

Re: es.po and small bug fix

[Jean-Marc Lasgouttes]

> "Lars" == Lars Gullik Bjønnes <[EMAIL PROTECTED]> writes:

Lars> 3. means to extract the needed informatin from the babel
Lars> .ldf files. This not be too hard and using the substring and the
Lars> regex class form the old 1.1.x series should help a lot.

It would not be too difficult to write a LaTeX script which inputs
.ldf files and spits out datafiles for LyX. We could either do it just
once and distribute the datafiles or do it at configure time (is that
useful?). 

The real problem I see is accents: in portugues.ldf, we have
 \def\refname{Refer\^encias}

What shall we do about that? The first idea is to translate to latin1
(with recode, for example). However, for some languages, latin2 (or
another one) would be a better choice.

So maybe creating the data files once in a semi automatic way will be
the best choice...

JMarc

Re: es.po and small bug fix

[Jean-Marc Lasgouttes]

> "Lars" == Lars Gullik Bjønnes <[EMAIL PROTECTED]> writes:

Lars> Note that we only care about the default menus, user modified
Lars> menus we can do nothing about. What do you mean by "hardcode
Lars> translations"? We will add the menu definitions file to the list
Lars> of files gettext scans for localization strings.

I mean that a user cannot, for example, put his own translation of
menus in his local directory and have LyX use it. I personally think
that this feature of being able to modify LyX behaviour at user level
is a very nice one.

JMarc

Re: es.po and small bug fix

[Lars Gullik Bjønnes]

Jean-Marc Lasgouttes <[EMAIL PROTECTED]> writes:

| I mean that a user cannot, for example, put his own translation of
| menus in his local directory and have LyX use it.

Why not?

| I personally think
| that this feature of being able to modify LyX behaviour at user level
| is a very nice one.

Agree.

Lgb

Re: es.po and small bug fix

[Lars Gullik Bjønnes]

Jean-Marc Lasgouttes <[EMAIL PROTECTED]> writes:

| > "Lars" == Lars Gullik Bjønnes <[EMAIL PROTECTED]> writes:
| 
| Lars> 3. means to extract the needed informatin from the babel
| Lars> .ldf files. This not be too hard and using the substring and the
| Lars> regex class form the old 1.1.x series should help a lot.
| 
| It would not be too difficult to write a LaTeX script which inputs
| .ldf files and spits out datafiles for LyX. We could either do it just
| once and distribute the datafiles or do it at configure time (is that
| useful?). 

We have three options on when to extract language strings from the
.ldf files:
1. static (we extract and distribute with lyx)
2. at configure time.
3. live from a running LyX.

These are no listed in my reverse prefered order.
If we could have a nice automatic-interface to 3. that would imho be
nicest, 2. is also almost equally nice and 1. should not be considered
at all.

| The real problem I see is accents: in portugues.ldf, we have
|  \def\refname{Refer\^encias}

Does \^ have special meaning in portugues? Or is it the regular accent
that insetlatexaccent is able to handle?

| What shall we do about that? The first idea is to translate to latin1
| (with recode, for example). However, for some languages, latin2 (or
| another one) would be a better choice.

I think we can solve this. AFAIK 8bit chars are not used in .ldf files
only (La)TeX accent commands, and we can handle those. 

| So maybe creating the data files once in a semi automatic way will be
| the best choice...

Fully automatic please...

Lgb

Re: es.po and small bug fix

[Jean-Marc Lasgouttes]

> "Lars" == Lars Gullik Bjønnes <[EMAIL PROTECTED]> writes:

Lars> We have three options on when to extract language strings from
Lars> the .ldf files: 1. static (we extract and distribute with lyx)
Lars> 2. at configure time. 3. live from a running LyX.

Lars> These are no listed in my reverse prefered order. If we could
Lars> have a nice automatic-interface to 3. that would imho be nicest,
Lars> 2. is also almost equally nice and 1. should not be considered
Lars> at all.

I think 2 is the simplest, since having latex do the parsing is safer.

Lars> Does \^ have special meaning in portugues? Or is it the regular
Lars> accent that insetlatexaccent is able to handle?

So, what about:
  \def\refname{%
{\cyr \CYRS\CYRp\CYRi\CYRs\CYRo\CYRk\space
  \CYRl\CYRi\CYRt\CYRe\CYRr\CYRa\CYRt\CYRu\CYRr\CYRy}}%

[I'll let you guess where this one came from]

JMarc

Re: es.po and small bug fix

[Jose Abilio Oliveira Matos]

On Wed, Oct 13, 1999 at 01:45:50PM +0200, Lars Gullik Bjønnes wrote:
> 
> | The real problem I see is accents: in portugues.ldf, we have
> |  \def\refname{Refer\^encias}
> 
> Does \^ have special meaning in portugues? Or is it the regular accent
> that insetlatexaccent is able to handle?
 
  The later. \^e is ê
 
>   Lgb

  For docbook and linuxdoc maybe we could use the latex translation, where
available.

-- 
José

Re: es.po and small bug fix

[Lars Gullik Bjønnes]

Jose Abilio Oliveira Matos <[EMAIL PROTECTED]> writes:

| On Wed, Oct 13, 1999 at 01:45:50PM +0200, Lars Gullik Bjønnes wrote:
| > 
| > | The real problem I see is accents: in portugues.ldf, we have
| > |  \def\refname{Refer\^encias}
| > 
| > Does \^ have special meaning in portugues? Or is it the regular accent
| > that insetlatexaccent is able to handle?
|  
|   The later. \^e is ê

Ok, then we already have the functions to parse and extract this.

|   For docbook and linuxdoc maybe we could use the latex translation, where
| available.

Yes, why not.

Lgb

Re: es.po and small bug fix

[Jean-Marc Lasgouttes]

> "Lars" == Lars Gullik Bjønnes <[EMAIL PROTECTED]> writes:

Lars> Jean-Marc Lasgouttes <[EMAIL PROTECTED]> writes: | I
Lars> mean that a user cannot, for example, put his own translation of
Lars> | menus in his local directory and have LyX use it.

Lars> Why not?

Because po files cannot be used like that. They are hardcoded to live
in /foo/share/locale/... So people who do not have root access and
want to develop their own translation cannot do that easily. Also, I
think it would be good to be able to distribute a msword menu layout
(complete with french translation, because I am french and I can do
it) and that people are able to use it without patching lyx. That's
what people can do now when adding a new textclass, and I think it is good.

And what about bind files translation? Do you plan to use gettext too? 

The idea I had is the following: we could separate all language
specific stuff in their own archive, like

lib/layout/fr_stdsections.inc
...
lib/doc/fr_Intro.lyx
...
lib/ui/fr_default.ui  (this is something I'd like to introduce later
   to define both menus and toolbars)
lib/bind/fr_cua.bind
po/fr.po  (not sure about this one)

This way, each translation team would be responsible for managing
*all* translations on their own.

Then one could do
tar zxvf lyx-1.1.2.tar.gz
cd lyx-1.1.2
tar zxvf lyx-fr-1.1.2.tar.gz (I think we should not have a lyx-1.1.2
  prefix in the i18n tar files so that
  they needn't be updated at each version) 
./configure
make

Instead of using this fr_ convention on files, we could also put
everything in a different directory (lib/fr/...).

The problem I see with using gettext everywhere is that we have to
resolve ambiguities; I do not know whether they exist right now, but I
am sure we will eventually come to cases where we want different
translations for a given string, and the solution will necessarily be
ugly. This is the major gettext limitation as far as I am concerned.

JMarc

Re: es.po and small bug fix

[Lars Gullik Bjønnes]

Jean-Marc Lasgouttes <[EMAIL PROTECTED]> writes:

| > "Lars" == Lars Gullik Bjønnes <[EMAIL PROTECTED]> writes:
| 
| Lars> We have three options on when to extract language strings from
| Lars> the .ldf files: 1. static (we extract and distribute with lyx)
| Lars> 2. at configure time. 3. live from a running LyX.
| 
| Lars> These are no listed in my reverse prefered order. If we could
| Lars> have a nice automatic-interface to 3. that would imho be nicest,
| Lars> 2. is also almost equally nice and 1. should not be considered
| Lars> at all.
| 
| I think 2 is the simplest, since having latex do the parsing is safer.
| 
| Lars> Does \^ have special meaning in portugues? Or is it the regular
| Lars> accent that insetlatexaccent is able to handle?
| 
| So, what about:
|   \def\refname{%
| {\cyr \CYRS\CYRp\CYRi\CYRs\CYRo\CYRk\space
|   \CYRl\CYRi\CYRt\CYRe\CYRr\CYRa\CYRt\CYRu\CYRr\CYRy}}%

We just need a module that knows how to display cyrillic, a lot of
these problems will go away/be easier to solve when/if we switch to
unicode.

I am beginning to leand towards using unicode internally in LyX all
the time.

Lgb

Re: es.po and small bug fix

[Lars Gullik Bjønnes]

Jean-Marc Lasgouttes <[EMAIL PROTECTED]> writes:

| > "Lars" == Lars Gullik Bjønnes <[EMAIL PROTECTED]> writes:
| 
| Lars> We have three options on when to extract language strings from
| Lars> the .ldf files: 1. static (we extract and distribute with lyx)
| Lars> 2. at configure time. 3. live from a running LyX.
| 
| Lars> These are no listed in my reverse prefered order. If we could
| Lars> have a nice automatic-interface to 3. that would imho be nicest,
| Lars> 2. is also almost equally nice and 1. should not be considered
| Lars> at all.
| 
| I think 2 is the simplest, since having latex do the parsing is safer.
| 
| Lars> Does \^ have special meaning in portugues? Or is it the regular
| Lars> accent that insetlatexaccent is able to handle?
| 
| So, what about:
|   \def\refname{%
| {\cyr \CYRS\CYRp\CYRi\CYRs\CYRo\CYRk\space
|   \CYRl\CYRi\CYRt\CYRe\CYRr\CYRa\CYRt\CYRu\CYRr\CYRy}}%

+ addition to prev mail:

I don't think it would be so bad of us to focus mainly on latin
charsets for the timebeeing. We could also consider moving to using
unicode internally fairly quick.

Lgb

Re: es.po and small bug fix

[Jean-Marc Lasgouttes]

> "Lars" == Lars Gullik Bjønnes <[EMAIL PROTECTED]> writes:

Lars> We just need a module that knows how to display cyrillic, a lot
Lars> of these problems will go away/be easier to solve when/if we
Lars> switch to unicode.

Lars> I am beginning to leand towards using unicode internally in LyX
Lars> all the time.

I agree, but this a long-term solution. The short-term solution I was
thinking about was to create (partly) by hand a configuration file
which has the strings in the encoding corresponding to the language.
When we have uncode and eveything it will be able to plug in without
much work the clean solution.

JMarc

Re: es.po and small bug fix

[Asger K. Alstrup Nielsen]

> Fully automatic please...

One note though:

Fully automatic seems best, but it is also the most risky. We do not have
control over which strange LaTeX installatinopneople have, and therefore
we would need to build a robust system if it has to work on everything
out there.

I think that a static system is fully adequate. It's not like these strings 
are changing every day.  Actually, I don't think they change at all once
they are done...

I think we should adopt a development model where we reduce risks.
That implies chosing the simple solutions sometimes.

Greets,

Asger

Re: es.po and small bug fix

[Lars Gullik Bjønnes]

"Asger K. Alstrup Nielsen" <[EMAIL PROTECTED]> writes:

| > Fully automatic please...
| 
| One note though:
| 
| Fully automatic seems best, but it is also the most risky. We do not have
| control over which strange LaTeX installatinopneople have, and therefore
| we would need to build a robust system if it has to work on everything
| out there.

That is impossible anyway...

| I think that a static system is fully adequate. It's not like these strings 
| are changing every day.  Actually, I don't think they change at all once
| they are done...

We should have a automatic way of updating these files anyway...
And it is to me a bit bad to supply 20+ languages with lyx.

Ok...what about this:

We supply scripts/code to do the extraction of language strings from
.ldf on install time. We also provide as a _separate_ package a
collection of language definition files. And of course we will always
supply the default/hardcoded strings.

| I think we should adopt a development model where we reduce risks.
| That implies chosing the simple solutions sometimes.

Sure...

Lgb

Re: es.po and small bug fix

[miyata]

"Asger K. Alstrup Nielsen" <[EMAIL PROTECTED]> wrote:

> > - muddle on with gettext
>
> This is the least intrusive solution, and thus the safest one.

Do you mean something like:

/* FileGetText: This is C. */
/* Use it as
   #define __(str) fgettext(\
 LibFileSearch(\
 "layout_messages", \
 current_view->currentBuffer()->params.language, \
 "mo").c_str(), \
 str)
*/
#include 
#include "gettext.h"
#include "gettextP.h"

extern char *find_msg(struct loaded_l10nfile *domain_file, const char *msgid);

char *fgettext(char *fullpath_to_msgobj, const char *msgid)
{
struct loaded_l10nfile *domain_file;
char *retval;

domain_file->filename = fullpath_to_msgobj;
_nl_load_domain (domain_file);
retval = find_msg (domain_file, msgid);

return retval ? retval : msgid;
}


?
The obvious problem with this approach is that we have to link GNU
version of libintl.  But if we are going to adopt this, then the
rest is to write a script to extract .po files from .ldf files.

Regards,
SMiyata

Re: es.po and small bug fix

[Lars Gullik Bjønnes]

"Asger K. Alstrup Nielsen" [EMAIL PROTECTED] writes:

|  I think Jean-Marc is right ;), if we introduce this we want it right
|  straight away and as this is document specific it's related to the
|  document and not to the locale. We have so many hacks in the source
| 
| I agree with the original poster that it's an improvement to translate
| the fixed text to the native language, and thus I think the patch should
| go in.
| It's really simple: We just have to mark the "Chapter" texts as gettext
| strings, and that's it. Why just have this small improvement? It's not
| yet another hack at all, but just a small thing that will make LyX
| easier to understand for children and others that don't understand
| English.

I am beginning to agree with Jean-Marc that gettext is unable to
handle this case. (a gettext written for C++ using the C++ notion of
locale would work)

Using gettext would be just a shorterm fix, and it would only be
correct when the locale lang is equal to the doc lang.

The Right Solution would to have a gettext that was written for C++'s
locale support (able to use several locales at once), but until we
have that we can either:

- muddle on with gettext
- have a lang file for each layout.

Lgb

Re: es.po and small bug fix

[Jean-Marc Lasgouttes]

 "Lars" == Lars Gullik Bjønnes [EMAIL PROTECTED] writes:

Lars I am beginning to agree with Jean-Marc that gettext is unable to
Lars handle this case. (a gettext written for C++ using the C++
Lars notion of locale would work)

Lars Using gettext would be just a shorterm fix, and it would only be
Lars correct when the locale lang is equal to the doc lang.

Lars - muddle on with gettext - have a lang file for each layout.

We have two things to do:

1) localize the name of the layouts in the GUI and the menus (once we
   have ported the new menu system). gettext is able to handle that,
   but this means we have to hardcode translations of things which ar
   enot compiled in. For me, this is a problem.

2) Make the GUI reflect the commands like \chaptername. I think we
   would need to add a concept of variables in layout files, and
   provide language files which define the variables correclt
   ydepending on the language. We should take the descriptions
   directly from babel, so that the translation job is minimal.

The first part is easy, the second would be a bit more work, but not
too much.

JMarc

Re: es.po and small bug fix

[Lars Gullik Bjønnes]

Jean-Marc Lasgouttes [EMAIL PROTECTED] writes:

| 1) localize the name of the layouts in the GUI and the menus (once we
|have ported the new menu system). gettext is able to handle that,
|but this means we have to hardcode translations of things which ar
|enot compiled in. For me, this is a problem.

Note that we only care about the default menus, user modified menus we
can do nothing about. What do you mean by "hardcode translations"?
We will add the menu definitions file to the list of files gettext
scans for localization strings.

| 2) Make the GUI reflect the commands like \chaptername. I think we
|would need to add a concept of variables in layout files, and
|provide language files which define the variables correclt
|ydepending on the language. We should take the descriptions
|directly from babel, so that the translation job is minimal.

We _have_ the babel language definitions files, and we could require
lyx to know about the location of these, either by using kpseawhich or
having the installer/user providing the path. Then a scan of the
definitions files should provide us with the information that we need.

Lgb

Re: es.po and small bug fix

[Lars Gullik Bjønnes]

"Asger K. Alstrup Nielsen" [EMAIL PROTECTED] writes:

|  Using gettext would be just a shorterm fix, and it would only be
|  correct when the locale lang is equal to the doc lang.
| 
| ...and therefore, we can't expect that we will have that in the shortterm.
| So, I think we should include the shortterm fix until we have the
| long term solution.
| 
|  The Right Solution would to have a gettext that was written for C++'s
|  locale support (able to use several locales at once), but until we
|  have that we can either:
|  
|  - muddle on with gettext
| 
| This is the least intrusive solution, and thus the safest one.
| 
|  - have a lang file for each layout.
| 
| Are the "Chapter" strings in the layout files?  I thought they were
| hard coded...

Defined in the layout files.

However it seems to me that the _real_ correct solution is to use the
strings that babel provides. This should not be too difficult...what
would be required:

1. use variables in layout files and have hardcoded values for these
   variables¹ in lyx. Layout files should also be able to declare/defines
   the variables that is uses.
2. a mapping from variable name to variable contents inside lyx. this
   would be a mapstring,string There would be one such map for each
   document/language. It needs to be per document since different
   documents in the same language does not need to use the same terms.
3. means to extract the needed informatin from the babel .ldf files.
   This not be too hard and using the substring and the regex class
   form the old 1.1.x series should help a lot.

This would actually be a quite nice project. And does not require a
lot of internal LyX knowledge. 

Lgb

¹ + Hardcoded in some data file most likely + the hardcoded values
could be gettextified. 

Re: es.po and small bug fix

[Asger K. Alstrup Nielsen]

 I am beginning to agree with Jean-Marc that gettext is unable to
 handle this case. (a gettext written for C++ using the C++ notion of
 locale would work)

Yes, gettext will have a hard time to handle this.  We need to implement
our own translation facility to do this right...

 Using gettext would be just a shorterm fix, and it would only be
 correct when the locale lang is equal to the doc lang.

...and therefore, we can't expect that we will have that in the shortterm.
So, I think we should include the shortterm fix until we have the
long term solution.

 The Right Solution would to have a gettext that was written for C++'s
 locale support (able to use several locales at once), but until we
 have that we can either:
 
 - muddle on with gettext

This is the least intrusive solution, and thus the safest one.

 - have a lang file for each layout.

Are the "Chapter" strings in the layout files?  I thought they were
hard coded...

Greets,

Asger

Re: es.po and small bug fix

[Lars Gullik Bjønnes]

"Asger K. Alstrup Nielsen" <[EMAIL PROTECTED]> writes:

| > I think Jean-Marc is right ;), if we introduce this we want it right
| > straight away and as this is document specific it's related to the
| > document and not to the locale. We have so many hacks in the source
| 
| I agree with the original poster that it's an improvement to translate
| the fixed text to the native language, and thus I think the patch should
| go in.
| It's really simple: We just have to mark the "Chapter" texts as gettext
| strings, and that's it. Why just have this small improvement? It's not
| yet another hack at all, but just a small thing that will make LyX
| easier to understand for children and others that don't understand
| English.

I am beginning to agree with Jean-Marc that gettext is unable to
handle this case. (a gettext written for C++ using the C++ notion of
locale would work)

Using gettext would be just a shorterm fix, and it would only be
correct when the locale lang is equal to the doc lang.

The Right Solution would to have a gettext that was written for C++'s
locale support (able to use several locales at once), but until we
have that we can either:

- muddle on with gettext
- have a lang file for each layout.

Lgb

Re: es.po and small bug fix

[Jean-Marc Lasgouttes]

> "Lars" == Lars Gullik Bjønnes <[EMAIL PROTECTED]> writes:

Lars> I am beginning to agree with Jean-Marc that gettext is unable to
Lars> handle this case. (a gettext written for C++ using the C++
Lars> notion of locale would work)

Lars> Using gettext would be just a shorterm fix, and it would only be
Lars> correct when the locale lang is equal to the doc lang.

Lars> - muddle on with gettext - have a lang file for each layout.

We have two things to do:

1) localize the name of the layouts in the GUI and the menus (once we
   have ported the new menu system). gettext is able to handle that,
   but this means we have to hardcode translations of things which ar
   enot compiled in. For me, this is a problem.

2) Make the GUI reflect the commands like \chaptername. I think we
   would need to add a concept of variables in layout files, and
   provide language files which define the variables correclt
   ydepending on the language. We should take the descriptions
   directly from babel, so that the translation job is minimal.

The first part is easy, the second would be a bit more work, but not
too much.

JMarc

Re: es.po and small bug fix

[Lars Gullik Bjønnes]

Jean-Marc Lasgouttes <[EMAIL PROTECTED]> writes:

| 1) localize the name of the layouts in the GUI and the menus (once we
|have ported the new menu system). gettext is able to handle that,
|but this means we have to hardcode translations of things which ar
|enot compiled in. For me, this is a problem.

Note that we only care about the default menus, user modified menus we
can do nothing about. What do you mean by "hardcode translations"?
We will add the menu definitions file to the list of files gettext
scans for localization strings.

| 2) Make the GUI reflect the commands like \chaptername. I think we
|would need to add a concept of variables in layout files, and
|provide language files which define the variables correclt
|ydepending on the language. We should take the descriptions
|directly from babel, so that the translation job is minimal.

We _have_ the babel language definitions files, and we could require
lyx to know about the location of these, either by using kpseawhich or
having the installer/user providing the path. Then a scan of the
definitions files should provide us with the information that we need.

Lgb

Re: es.po and small bug fix

[Lars Gullik Bjønnes]

"Asger K. Alstrup Nielsen" <[EMAIL PROTECTED]> writes:

| > Using gettext would be just a shorterm fix, and it would only be
| > correct when the locale lang is equal to the doc lang.
| 
| ...and therefore, we can't expect that we will have that in the shortterm.
| So, I think we should include the shortterm fix until we have the
| long term solution.
| 
| > The Right Solution would to have a gettext that was written for C++'s
| > locale support (able to use several locales at once), but until we
| > have that we can either:
| > 
| > - muddle on with gettext
| 
| This is the least intrusive solution, and thus the safest one.
| 
| > - have a lang file for each layout.
| 
| Are the "Chapter" strings in the layout files?  I thought they were
| hard coded...

Defined in the layout files.

However it seems to me that the _real_ correct solution is to use the
strings that babel provides. This should not be too difficult...what
would be required:

1. use variables in layout files and have hardcoded values for these
   variables¹ in lyx. Layout files should also be able to declare/defines
   the variables that is uses.
2. a mapping from variable name to variable contents inside lyx. this
   would be a map There would be one such map for each
   document/language. It needs to be per document since different
   documents in the same language does not need to use the same terms.
3. means to extract the needed informatin from the babel .ldf files.
   This not be too hard and using the substring and the regex class
   form the old 1.1.x series should help a lot.

This would actually be a quite nice project. And does not require a
lot of internal LyX knowledge. 

Lgb

¹ + Hardcoded in some data file most likely + the hardcoded values
could be gettextified. 

Re: es.po and small bug fix

[Asger K. Alstrup Nielsen]

> I am beginning to agree with Jean-Marc that gettext is unable to
> handle this case. (a gettext written for C++ using the C++ notion of
> locale would work)

Yes, gettext will have a hard time to handle this.  We need to implement
our own translation facility to do this right...

> Using gettext would be just a shorterm fix, and it would only be
> correct when the locale lang is equal to the doc lang.

...and therefore, we can't expect that we will have that in the shortterm.
So, I think we should include the shortterm fix until we have the
long term solution.

> The Right Solution would to have a gettext that was written for C++'s
> locale support (able to use several locales at once), but until we
> have that we can either:
> 
> - muddle on with gettext

This is the least intrusive solution, and thus the safest one.

> - have a lang file for each layout.

Are the "Chapter" strings in the layout files?  I thought they were
hard coded...

Greets,

Asger

Re: es.po and small bug fix

[Juergen Vigna]

On 08-Oct-99 David S de Lis wrote:
 Hi all,

Hi David!

[sniped good explanation]
 
 I think I'd like to hear other developers points of views regarding this
 issue. As I said before, it's not big thing, but I thought it deserved a
 defense... :)

I think Jean-Marc is right ;), if we introduce this we want it right
straight away and as this is document specific it's related to the
document and not to the locale. We have so many hacks in the source
code that IMO if we introduce new stuff now we should do the right
thing from the beginning. I for myself have to write documents in
italian, german and english. I always use a english locale (as I find
it a cleaner interface) and then select the apropriate document language,
to write my text. IMO it's not too hard to introduce this so that it
works good right from the beginning.

Greets Jürgen

-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._

Dr. Jürgen Vigna  E-Mail: [EMAIL PROTECTED]
Gerbergasse 60Tel:+39-0471-450260
I-39100 Bozen Fax:+39-0471-970042
ITALY Web:http://www.sad.it/~jug

Lensmen eat Jedi for breakfast.

-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._

Re: es.po and small bug fix

[Asger K. Alstrup Nielsen]

 I think Jean-Marc is right ;), if we introduce this we want it right
 straight away and as this is document specific it's related to the
 document and not to the locale. We have so many hacks in the source

I agree with the original poster that it's an improvement to translate
the fixed text to the native language, and thus I think the patch should
go in.
It's really simple: We just have to mark the "Chapter" texts as gettext
strings, and that's it. Why just have this small improvement? It's not
yet another hack at all, but just a small thing that will make LyX
easier to understand for children and others that don't understand
English.

Greets,

Asger

Re: es.po and small bug fix

[Juergen Vigna]

On 08-Oct-99 David S de Lis wrote:
> Hi all,

Hi David!

[sniped good explanation]
> 
> I think I'd like to hear other developers points of views regarding this
> issue. As I said before, it's not big thing, but I thought it deserved a
> defense... :)

I think Jean-Marc is right ;), if we introduce this we want it right
straight away and as this is document specific it's related to the
document and not to the locale. We have so many hacks in the source
code that IMO if we introduce new stuff now we should do the right
thing from the beginning. I for myself have to write documents in
italian, german and english. I always use a english locale (as I find
it a cleaner interface) and then select the apropriate document language,
to write my text. IMO it's not too hard to introduce this so that it
works good right from the beginning.

Greets Jürgen

-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._

Dr. Jürgen Vigna  E-Mail: [EMAIL PROTECTED]
Gerbergasse 60Tel:+39-0471-450260
I-39100 Bozen Fax:+39-0471-970042
ITALY Web:http://www.sad.it/~jug

Lensmen eat Jedi for breakfast.

-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._

Re: es.po and small bug fix

[Asger K. Alstrup Nielsen]

> I think Jean-Marc is right ;), if we introduce this we want it right
> straight away and as this is document specific it's related to the
> document and not to the locale. We have so many hacks in the source

I agree with the original poster that it's an improvement to translate
the fixed text to the native language, and thus I think the patch should
go in.
It's really simple: We just have to mark the "Chapter" texts as gettext
strings, and that's it. Why just have this small improvement? It's not
yet another hack at all, but just a small thing that will make LyX
easier to understand for children and others that don't understand
English.

Greets,

Asger

Re: es.po and small bug fix

[David S de Lis]

Hi all,

On 5 Oct 1999, Jean-Marc Lasgouttes wrote:

: David two more hackings (text.C and lyx_cb.C)
: David that allows to see the 'Chapter x' and 'Part #' on-screen in
: David the current locale as well as seeing 'Chapter x' in current
: David locale on the TOC popup... and corresponding updated es.po
: David (1124 messages translated! :) this is probably the only time
: David es.po will be ahead the 'official' lyx.pot if the patches are
: David accepted :)
: 
: I will not apply this patch since the language in which 'Chapter' is
: written is not the language of the GUI (locale) but the language of
: the document. For example, if I have LANG=fr and edit english
: documents, I do not want to see chapters apprear as Chapitres. While I
: agree that the problem is real, the solution is not right...

I replied to Jean-Marc privately but after giving some more thoughts (while
travelling around the clock) and even though I agree with his explanation
and I am already digging into the code for a solution, I still think what I
did is useful (and therefore should be patched into the main source).

I was thinking about the use most people will give to LyX and my
conclusions are these two:

- most users will spend most of the time using LyX under their
  locale if support is available
- most documents created will be in the user's own language,
  which is likely to be supported by LyX (or either support
  can be created via GNU gettext po files)

I'll use JM's example to point out my argumentation. If I have LANG=fr
when writing an english document, I'll see 'Chapitre' instead of
'Chapter'. But currently I'll see 'Chapter' even when I am writing a
document in french (or any other language). I am just wondering why
english is a better default behavior than the current user's locale. I
mean, if they decide to have all LyX GUI (and maybe all their OS) in
'fr', and for most users, most docuemnts will be written in french,
why should 'Chapter' be a better default than 'Chapitre'? It will be
adecuate for much more many cases than 'Chapter' by statistical use.

I am specially interested in LyX working at peak efficiency in Spanish
because there is a big potential user base in Mexico (which is moving
all their High School to GNU/Linux) that will benefit from LyX
superior document creation capabilities. As these young beings create
documents (probably school related) most of their work will be done in
spanish (and hopefully using 'es_*' locale). I think having 'Chapter'
as default is not better than having 'Capítulo', even if it's not the
best solution. But I think it is a better solution than the current
one.

Now, I am not defending the patches because they are mine. I am
defending them because I did them under suggestion from my 12-years old
cousin (whom I was showing a SF novel I am writing (in spanish) and
asked me why Linux is in english but LyX is in spanish and why instead
'Capítulo 1' it said 'Chapter 1'). Me, I don't particularly mind how
it is shown on-screen if the printed output is correct (which it is
because laTeX takes care of it) but I think it is a user friendlier
behavior (actually not only 'Chapter' and 'Part' should be translated,
but also the 'foot' of footnotes, 'note' of notes, c... (Appendices,
margin notes...))

I am looking into the possibility of doing this behavior (on-screen
labels in custom language) document language-dependent (although it is
starting to appear a good challenge) and I certainly invite any others
that may be interested in this feature (which is not really a Big
Issue, rather a minor thing for people with little time to the Bigger
things like myself) to join me; but while I/we don't get possitive
results, I'd add the 'locale on-screen' behavior (even if just as an
option, configurable, rc, compile-time; I can change them to fit any
wish) for those many cases where the document language is the locale
language and, thus, they are indeed correct (even if just a hack and
by pure luck).

I think I'd like to hear other developers points of views regarding this
issue. As I said before, it's not big thing, but I thought it deserved a
defense... :)

(please Cc any post to me, although I should be able to check the archives,
right?)

: Could you redo an es.po which does not contain the translations
: related to this patch?

I am sending it attached to this message. It has some typos and wrong
numbers corrected as well, so it's better than the other one anyway... :)

Well, just my E0.02... :)

laters,
d@

PS -
: David I am thinking whether it would be convenient translating the
: David layouts in the drop down menu for the sake of
: 
: This would be suitable indeed, since the name of the layout in the GUI
: should march the locale. I am not sure however of where this
: translation should be done. Lars prefers po files (for consistency),
: but I think that doing the translation in layout files would be easier
: to maintain (not really sure...).

I 

Re: es.po and small bug fix

[David S de Lis]

Hi all,

On 5 Oct 1999, Jean-Marc Lasgouttes wrote:

: David> two more hackings (text.C and lyx_cb.C)
: David> that allows to see the 'Chapter x' and 'Part #' on-screen in
: David> the current locale as well as seeing 'Chapter x' in current
: David> locale on the TOC popup... and corresponding updated es.po
: David> (1124 messages translated! :) this is probably the only time
: David> es.po will be ahead the 'official' lyx.pot if the patches are
: David> accepted :)
: 
: I will not apply this patch since the language in which 'Chapter' is
: written is not the language of the GUI (locale) but the language of
: the document. For example, if I have LANG=fr and edit english
: documents, I do not want to see chapters apprear as Chapitres. While I
: agree that the problem is real, the solution is not right...

I replied to Jean-Marc privately but after giving some more thoughts (while
travelling around the clock) and even though I agree with his explanation
and I am already digging into the code for a solution, I still think what I
did is useful (and therefore should be patched into the main source).

I was thinking about the use most people will give to LyX and my
conclusions are these two:

- most users will spend most of the time using LyX under their
  locale if support is available
- most documents created will be in the user's own language,
  which is likely to be supported by LyX (or either support
  can be created via GNU gettext po files)

I'll use JM's example to point out my argumentation. If I have LANG=fr
when writing an english document, I'll see 'Chapitre' instead of
'Chapter'. But currently I'll see 'Chapter' even when I am writing a
document in french (or any other language). I am just wondering why
english is a better default behavior than the current user's locale. I
mean, if they decide to have all LyX GUI (and maybe all their OS) in
'fr', and for most users, most docuemnts will be written in french,
why should 'Chapter' be a better default than 'Chapitre'? It will be
adecuate for much more many cases than 'Chapter' by statistical use.

I am specially interested in LyX working at peak efficiency in Spanish
because there is a big potential user base in Mexico (which is moving
all their High School to GNU/Linux) that will benefit from LyX
superior document creation capabilities. As these young beings create
documents (probably school related) most of their work will be done in
spanish (and hopefully using 'es_*' locale). I think having 'Chapter'
as default is not better than having 'Capítulo', even if it's not the
best solution. But I think it is a better solution than the current
one.

Now, I am not defending the patches because they are mine. I am
defending them because I did them under suggestion from my 12-years old
cousin (whom I was showing a SF novel I am writing (in spanish) and
asked me why Linux is in english but LyX is in spanish and why instead
'Capítulo 1' it said 'Chapter 1'). Me, I don't particularly mind how
it is shown on-screen if the printed output is correct (which it is
because laTeX takes care of it) but I think it is a user friendlier
behavior (actually not only 'Chapter' and 'Part' should be translated,
but also the 'foot' of footnotes, 'note' of notes,  (Appendices,
margin notes...))

I am looking into the possibility of doing this behavior (on-screen
labels in custom language) document language-dependent (although it is
starting to appear a good challenge) and I certainly invite any others
that may be interested in this feature (which is not really a Big
Issue, rather a minor thing for people with little time to the Bigger
things like myself) to join me; but while I/we don't get possitive
results, I'd add the 'locale on-screen' behavior (even if just as an
option, configurable, rc, compile-time; I can change them to fit any
wish) for those many cases where the document language is the locale
language and, thus, they are indeed correct (even if just a hack and
by pure luck).

I think I'd like to hear other developers points of views regarding this
issue. As I said before, it's not big thing, but I thought it deserved a
defense... :)

(please Cc any post to me, although I should be able to check the archives,
right?)

: Could you redo an es.po which does not contain the translations
: related to this patch?

I am sending it attached to this message. It has some typos and wrong
numbers corrected as well, so it's better than the other one anyway... :)

Well, just my E0.02... :)

laters,
d@

PS -
: David> I am thinking whether it would be convenient translating the
: David> layouts in the drop down menu for the sake of
: 
: This would be suitable indeed, since the name of the layout in the GUI
: should march the locale. I am not sure however of where this
: translation should be done. Lars prefers po files (for consistency),
: but I think that doing the translation in layout files would be easier
: to maintain (not really sure...).

Re: es.po and small bug fix

[Jean-Marc Lasgouttes]

 "Lars" == Lars Gullik Bjønnes [EMAIL PROTECTED] writes:

Lars David S de Lis [EMAIL PROTECTED] writes: | I am sending along,
Lars as well as the bug fix to minibuffer.C (against | 1.0.4pre8),
Lars two more hackings (text.C and lyx_cb.C) that allows to see the |
Lars 'Chapter x' and 'Part #' on-screen in the current locale as well
Lars as seeing | 'Chapter x' in current locale on the TOC popup...
Lars and corresponding updated | es.po (1124 messages translated! :)
Lars this is probably the only time es.po | will be ahead the
Lars 'official' lyx.pot if the patches are accepted :)

Lars Of course I should have told you this earlier. But I really
Lars don't like patches that both touch po files and source files in
Lars the same patch.

Lars Especially when it comes to backing out patches this is
Lars troublesome. Also if the fixes to minibuffer, text and lyx_cb
Lars are not relatet they should be given as three patches.

Note that one can always apply the patch and do the commit separately
in cvs. BTW, do you prefer a lot of small commits or are medium sized
chucks of unrelated things good enough?

JMarc

Re: es.po and small bug fix

[Jean-Marc Lasgouttes]

 "David" == David S de Lis [EMAIL PROTECTED] writes:

David I am sending along, as well as the bug fix to minibuffer.C
David (against 1.0.4pre8), 

I'll apply this minibuffer bugfix.

David two more hackings (text.C and lyx_cb.C)
David that allows to see the 'Chapter x' and 'Part #' on-screen in
David the current locale as well as seeing 'Chapter x' in current
David locale on the TOC popup... and corresponding updated es.po
David (1124 messages translated! :) this is probably the only time
David es.po will be ahead the 'official' lyx.pot if the patches are
David accepted :)

I will not apply this patch since the language in which 'Chapter' is
written is not the language of the GUI (locale) but the language of
the document. For example, if I have LANG=fr and edit english
documents, I do not want to see chapters apprear as Chapitres. While I
agree that the problem is real, the solution is not right...

Could you redo an es.po which does not contain the translations
related to this patch?

David I am thinking whether it would be convenient translating the
David layouts in the drop down menu for the sake of
David non-english/non-LaTeX users (I am specially thinking about
David Mexican high school students) so a suitable translation is
David provided using gettext... I'd appreciate any suggestions (and
David pro's and con's)

This would be suitable indeed, since the name of the layout in the GUI
should march the locale. I am not sure however of where this
translation should be done. Lars prefers po files (for consistency),
but I think that doing the translation in layout files would be easier
to maintain (not really sure...).

JMarc

Re: es.po and small bug fix

[Lars Gullik Bjønnes]

Jean-Marc Lasgouttes [EMAIL PROTECTED] writes:

| This would be suitable indeed, since the name of the layout in the GUI
| should march the locale. I am not sure however of where this
| translation should be done. Lars prefers po files (for consistency),
| but I think that doing the translation in layout files would be easier
| to maintain (not really sure...).

So you want to have additional "po-equivalent files"? How do you want
this? Scattered around in the layout files?

Po files, is the way to go. And can easily be achieved. In the long
run this will be the easiest. And new layout files that uses the same
terms as old ones will automatically benefit.

Lgb

Re: es.po and small bug fix

[Jean-Marc Lasgouttes]

 "Lars" == Lars Gullik Bjønnes [EMAIL PROTECTED] writes:

Lars So you want to have additional "po-equivalent files"? How do you
Lars want this? Scattered around in the layout files?

Something like 

fr_stdsections.inc:
---
Input* stdsections.inc

Style Chapter
  GUIName   Chapitre
End


Then, when trying to read a layout or inc file, the localized version
should be found first (except with Input*, which would search for the
exact name). Then any layout file using stdsections.inc would see its
layout names translated. This holds for LabelString too (when used as
helpers in letter or slides classes).

Lars Po files, is the way to go. And can easily be achieved. In the
Lars long run this will be the easiest. And new layout files that
Lars uses the same terms as old ones will automatically benefit.

It will not be as simple as that, unfortunately. For example, what
about configurable menus we will soon backport? Should they be
translated in po files too? This would make the `themability' (as in
distributing custom menus and toolbars) of lyx much more difficult to
achieve, since a part of the menu and textclasses definition would be
in practice hardcoded into lyx.

JMarc

Re: es.po and small bug fix

[Jean-Marc Lasgouttes]

> "Lars" == Lars Gullik Bjønnes <[EMAIL PROTECTED]> writes:

Lars> David S de Lis <[EMAIL PROTECTED]> writes: | I am sending along,
Lars> as well as the bug fix to minibuffer.C (against | 1.0.4pre8),
Lars> two more hackings (text.C and lyx_cb.C) that allows to see the |
Lars> 'Chapter x' and 'Part #' on-screen in the current locale as well
Lars> as seeing | 'Chapter x' in current locale on the TOC popup...
Lars> and corresponding updated | es.po (1124 messages translated! :)
Lars> this is probably the only time es.po | will be ahead the
Lars> 'official' lyx.pot if the patches are accepted :)

Lars> Of course I should have told you this earlier. But I really
Lars> don't like patches that both touch po files and source files in
Lars> the same patch.

Lars> Especially when it comes to backing out patches this is
Lars> troublesome. Also if the fixes to minibuffer, text and lyx_cb
Lars> are not relatet they should be given as three patches.

Note that one can always apply the patch and do the commit separately
in cvs. BTW, do you prefer a lot of small commits or are medium sized
chucks of unrelated things good enough?

JMarc

Re: es.po and small bug fix

[Jean-Marc Lasgouttes]

> "David" == David S de Lis <[EMAIL PROTECTED]> writes:

David> I am sending along, as well as the bug fix to minibuffer.C
David> (against 1.0.4pre8), 

I'll apply this minibuffer bugfix.

David> two more hackings (text.C and lyx_cb.C)
David> that allows to see the 'Chapter x' and 'Part #' on-screen in
David> the current locale as well as seeing 'Chapter x' in current
David> locale on the TOC popup... and corresponding updated es.po
David> (1124 messages translated! :) this is probably the only time
David> es.po will be ahead the 'official' lyx.pot if the patches are
David> accepted :)

I will not apply this patch since the language in which 'Chapter' is
written is not the language of the GUI (locale) but the language of
the document. For example, if I have LANG=fr and edit english
documents, I do not want to see chapters apprear as Chapitres. While I
agree that the problem is real, the solution is not right...

Could you redo an es.po which does not contain the translations
related to this patch?

David> I am thinking whether it would be convenient translating the
David> layouts in the drop down menu for the sake of
David> non-english/non-LaTeX users (I am specially thinking about
David> Mexican high school students) so a suitable translation is
David> provided using gettext... I'd appreciate any suggestions (and
David> pro's and con's)

This would be suitable indeed, since the name of the layout in the GUI
should march the locale. I am not sure however of where this
translation should be done. Lars prefers po files (for consistency),
but I think that doing the translation in layout files would be easier
to maintain (not really sure...).

JMarc

Re: es.po and small bug fix

[Lars Gullik Bjønnes]

Jean-Marc Lasgouttes <[EMAIL PROTECTED]> writes:

| This would be suitable indeed, since the name of the layout in the GUI
| should march the locale. I am not sure however of where this
| translation should be done. Lars prefers po files (for consistency),
| but I think that doing the translation in layout files would be easier
| to maintain (not really sure...).

So you want to have additional "po-equivalent files"? How do you want
this? Scattered around in the layout files?

Po files, is the way to go. And can easily be achieved. In the long
run this will be the easiest. And new layout files that uses the same
terms as old ones will automatically benefit.

Lgb

Re: es.po and small bug fix

[Jean-Marc Lasgouttes]

> "Lars" == Lars Gullik Bjønnes <[EMAIL PROTECTED]> writes:

Lars> So you want to have additional "po-equivalent files"? How do you
Lars> want this? Scattered around in the layout files?

Something like 

fr_stdsections.inc:
---
Input* stdsections.inc

Style Chapter
  GUIName   Chapitre
End


Then, when trying to read a layout or inc file, the localized version
should be found first (except with Input*, which would search for the
exact name). Then any layout file using stdsections.inc would see its
layout names translated. This holds for LabelString too (when used as
helpers in letter or slides classes).

Lars> Po files, is the way to go. And can easily be achieved. In the
Lars> long run this will be the easiest. And new layout files that
Lars> uses the same terms as old ones will automatically benefit.

It will not be as simple as that, unfortunately. For example, what
about configurable menus we will soon backport? Should they be
translated in po files too? This would make the `themability' (as in
distributing custom menus and toolbars) of lyx much more difficult to
achieve, since a part of the menu and textclasses definition would be
in practice hardcoded into lyx.

JMarc

Re: es.po and small bug fix

[Jean-Marc Lasgouttes]

 "David" == David S de Lis [EMAIL PROTECTED] writes:

David I have updated es.po as to version 1.0.4pre8, I am sorry if I
David am late for 1.0.4 :(

David I am also sending a hack to allow i18n guys (like me) to see
David the welcome message in the minibuffer when LyX starts (which
David was skipped due to a non gettext'ed string...)

Hello,

A small problem with your patch: it touches form1.fd for no apparent
reason, and contains a large string of ^@ (null character). Could you
redo it?

JMarc

Re: es.po and small bug fix

[David S de Lis]

Hi again,

On 4 Oct 1999, Jean-Marc Lasgouttes wrote:

:  "David" == David S de Lis [EMAIL PROTECTED] writes:
: 
: David I have updated es.po as to version 1.0.4pre8, I am sorry if I
: David am late for 1.0.4 :(
: 
: David I am also sending a hack to allow i18n guys (like me) to see
: David the welcome message in the minibuffer when LyX starts (which
: David was skipped due to a non gettext'ed string...)
: 
: Hello,
: 
: A small problem with your patch: it touches form1.fd for no apparent
: reason, and contains a large string of ^@ (null character). Could you
: redo it?

Of course, I noticed that myself yesterday... sorry 'bout that... :/
regarding the '^@'s, I have no idea... maybe is a locale thing? (I don't
think so, but...)

I am sending along, as well as the bug fix to minibuffer.C (against
1.0.4pre8), two more hackings (text.C and lyx_cb.C) that allows to see the
'Chapter x' and 'Part #' on-screen in the current locale as well as seeing
'Chapter x' in current locale on the TOC popup... and corresponding updated
es.po (1124 messages translated! :) this is probably the only time es.po
will be ahead the 'official' lyx.pot if the patches are accepted :)

I am thinking whether it would be convenient translating the layouts in the
drop down menu for the sake of non-english/non-LaTeX users (I am specially
thinking about Mexican high school students) so a suitable translation is
provided using gettext... I'd appreciate any suggestions (and pro's and
con's)

I am off town and will be for a couple of days or so, thus there is time to
discuss this if needed... :)

Thanks and laters,
d@ "hope it goes thru ok this time"

 Newest es.po and some hacks...

Re: es.po and small bug fix

[Lars Gullik Bjønnes]

David S de Lis [EMAIL PROTECTED] writes:

| I am sending along, as well as the bug fix to minibuffer.C (against
| 1.0.4pre8), two more hackings (text.C and lyx_cb.C) that allows to see the
| 'Chapter x' and 'Part #' on-screen in the current locale as well as seeing
| 'Chapter x' in current locale on the TOC popup... and corresponding updated
| es.po (1124 messages translated! :) this is probably the only time es.po
| will be ahead the 'official' lyx.pot if the patches are accepted :)

Of course I should have told you this earlier. But I really don't like
patches that both touch po files and source files in the same patch.

Especially when it comes to backing out patches this is troublesome.
Also if the fixes to minibuffer, text and lyx_cb are not relatet they
should be given as three patches.

This is one of the reason why the makepatch script has been removed
from the devel series. (if not I will remove it)

Lgb

Re: es.po and small bug fix

[Jean-Marc Lasgouttes]

> "David" == David S de Lis <[EMAIL PROTECTED]> writes:

David> I have updated es.po as to version 1.0.4pre8, I am sorry if I
David> am late for 1.0.4 :(

David> I am also sending a hack to allow i18n guys (like me) to see
David> the welcome message in the minibuffer when LyX starts (which
David> was skipped due to a non gettext'ed string...)

Hello,

A small problem with your patch: it touches form1.fd for no apparent
reason, and contains a large string of ^@ (null character). Could you
redo it?

JMarc

Re: es.po and small bug fix

[David S de Lis]

Hi again,

On 4 Oct 1999, Jean-Marc Lasgouttes wrote:

: > "David" == David S de Lis <[EMAIL PROTECTED]> writes:
: 
: David> I have updated es.po as to version 1.0.4pre8, I am sorry if I
: David> am late for 1.0.4 :(
: 
: David> I am also sending a hack to allow i18n guys (like me) to see
: David> the welcome message in the minibuffer when LyX starts (which
: David> was skipped due to a non gettext'ed string...)
: 
: Hello,
: 
: A small problem with your patch: it touches form1.fd for no apparent
: reason, and contains a large string of ^@ (null character). Could you
: redo it?

Of course, I noticed that myself yesterday... sorry 'bout that... :/
regarding the '^@'s, I have no idea... maybe is a locale thing? (I don't
think so, but...)

I am sending along, as well as the bug fix to minibuffer.C (against
1.0.4pre8), two more hackings (text.C and lyx_cb.C) that allows to see the
'Chapter x' and 'Part #' on-screen in the current locale as well as seeing
'Chapter x' in current locale on the TOC popup... and corresponding updated
es.po (1124 messages translated! :) this is probably the only time es.po
will be ahead the 'official' lyx.pot if the patches are accepted :)

I am thinking whether it would be convenient translating the layouts in the
drop down menu for the sake of non-english/non-LaTeX users (I am specially
thinking about Mexican high school students) so a suitable translation is
provided using gettext... I'd appreciate any suggestions (and pro's and
con's)

I am off town and will be for a couple of days or so, thus there is time to
discuss this if needed... :)

Thanks and laters,
d@ "hope it goes thru ok this time"

 Newest es.po and some hacks...

Re: es.po and small bug fix

[Lars Gullik Bjønnes]

David S de Lis <[EMAIL PROTECTED]> writes:

| I am sending along, as well as the bug fix to minibuffer.C (against
| 1.0.4pre8), two more hackings (text.C and lyx_cb.C) that allows to see the
| 'Chapter x' and 'Part #' on-screen in the current locale as well as seeing
| 'Chapter x' in current locale on the TOC popup... and corresponding updated
| es.po (1124 messages translated! :) this is probably the only time es.po
| will be ahead the 'official' lyx.pot if the patches are accepted :)

Of course I should have told you this earlier. But I really don't like
patches that both touch po files and source files in the same patch.

Especially when it comes to backing out patches this is troublesome.
Also if the fixes to minibuffer, text and lyx_cb are not relatet they
should be given as three patches.

This is one of the reason why the makepatch script has been removed
from the devel series. (if not I will remove it)

Lgb

es.po and small bug fix

[David S de Lis]

Hi all!

I am back (sorta). They killed my old server rather badly (and without
notice)

I am hoping to find an email account that can support the burden of some
mailing lists... once I got it, I'll subscribe again...

I have updated es.po as to version 1.0.4pre8, I am sorry if I am late for
1.0.4 :(

I am also sending a hack to allow i18n guys (like me) to see the welcome
message in the minibuffer when LyX starts (which was skipped due to a non
gettext'ed string...)

Also updates CHANGES and lib/CREDITS (if you find it appropriate)

I am working on some more i18n issues in LyX, but these may take a bit
longer...

Well, this program is getting really incredible, great job, gang! :)
Congratulations

laters,
d@

 Patch for 1.0.4pre8, es.po and minibuffer.C

es.po and small bug fix

[David S de Lis]

Hi all!

I am back (sorta). They killed my old server rather badly (and without
notice)

I am hoping to find an email account that can support the burden of some
mailing lists... once I got it, I'll subscribe again...

I have updated es.po as to version 1.0.4pre8, I am sorry if I am late for
1.0.4 :(

I am also sending a hack to allow i18n guys (like me) to see the welcome
message in the minibuffer when LyX starts (which was skipped due to a non
gettext'ed string...)

Also updates CHANGES and lib/CREDITS (if you find it appropriate)

I am working on some more i18n issues in LyX, but these may take a bit
longer...

Well, this program is getting really incredible, great job, gang! :)
Congratulations

laters,
d@

 Patch for 1.0.4pre8, es.po and minibuffer.C