Translation of ConTeXt interface

older
Fwd: Continued fractions in ConTeXt

Garulfo

26 Jun 2020 26 Jun '20

4:27 a.m.

Thanks a lot Wolfang for your answer. I have 5 additional questions... sorry. -----------------------------------------------------------

...

...
\placeFLOAT becomes \placerFLOAT \startplaceFLOAT becomes \debutplacerFLOAT \placerchemical becomes \placerchemical \startplacerchemical becomes \debutplacerchemical

\placefigure is a combination of the element "place" (\e!place) and the variable "figure" (\v!figure) \startplacefigure is a combination of the elements "start" (\e!start) and "place" (\e!place) and the variable "figure" (\v!figure.)

So, I'm still doing something wrong, because changing the translation of "figure" in "mult-def.lua" (in the part "variables"), only affect : 1- command "\startfigure \stopfigure" 2- "figure" in "\setuppageinjection" > alternative = figure buffer... ----------------------------------------------------------- I get another difficulty with \startitemize and \stopitemize the translation of the variable "itemize" has no impact on the setup-fr.pdf file produced with : context --interface=fr --global --result=setup-fr x-setups-overview.mkiv But, I just found that if I actually use the translated commands in a test.tex file, it just works. % interface=fr \debuttexte \debutlister \elem first \elem second \finlister \fintexte What should I do in order to have a setup-fr.pdf file that shows the translations actually available ? ----------------------------------------------------------- With the translation of the command textwidth, I can use "largeur=0.5\largeurtexte" (cool !) But this command is not listed in setup-fr.pdf. Is there a way to add these basic commands to setup-fr.pdf ? ----------------------------------------------------------- Math. I get the following error : fonts > preloading latin modern fonts (second stage) fonts > defining > font with asked name 'fichier' is not found using lookup 'file' fonts > defining > unknown font 'fichier', loading aborted I suppose that due to the translation of "file" to "fichier". It's OK when I switch back to - setupstrings cd:file ==> file - variables file ==> file How can I translate the variable "file" into fichier, without messing with fonts (and maybe other file related functions) -----------------------------------------------------------

...

Delimited command are problematic (especially when they change catcodes), e.g. \startluacode use \stopluacode as hard coded delimiter for the environment. While it is easy to create a synonym for \startluacode this isn't the case for \stopluacode because the environment always look for \stopluacode as stopper and alternative names are ignored.

\startsection \stopsection and \startformula \stopformula seem OK. How can I identify the delimited commands that should not be translated in order to avoid this issue. ----------------------------------------------------------- Thanks again

Show replies by date

Wolfgang Schuster

26 Jun 26 Jun

6:16 a.m.

...

Thanks a lot Wolfang for your answer. I have 5 additional questions... sorry.

-----------------------------------------------------------

...
...
      \placeFLOAT           becomes \placerFLOAT       \startplaceFLOAT      becomes \debutplacerFLOAT       \placerchemical       becomes \placerchemical       \startplacerchemical becomes \debutplacerchemical \placefigure is a combination of the element "place" (\e!place) and the variable "figure" (\v!figure) \startplacefigure is a combination of the elements "start" (\e!start) and "place" (\e!place) and the variable "figure" (\v!figure.)

So, I'm still doing something wrong, because changing the translation of "figure" in "mult-def.lua" (in the part "variables"), only affect :

1- command "\startfigure    \stopfigure" 2- "figure" in "\setuppageinjection" > alternative = figure buffer... You have to provide your modified mult-def.lua file, otherwise there is no way to check what's wrong. I get another difficulty with \startitemize and \stopitemize

the translation of the variable "itemize" has no impact on the setup-fr.pdf file produced with :

context --interface=fr --global --result=setup-fr x-setups-overview.mkiv

But, I just found that if I actually use the translated commands in a test.tex file, it just works.

% interface=fr \debuttexte \debutlister \elem first \elem second \finlister \fintexte

What should I do in order to have a setup-fr.pdf file that shows the translations actually available ? Same as above, provide your translations. With the translation of the command textwidth, I can use "largeur=0.5\largeurtexte" (cool !)

But this command is not listed in setup-fr.pdf. Is there a way to add these basic commands to setup-fr.pdf ? \textwidth is the name of a dimen register and no register names are listed. Math. I get the following error :

fonts > preloading latin modern fonts (second stage) fonts > defining > font with asked name 'fichier' is not found using lookup 'file' fonts > defining > unknown font 'fichier', loading aborted

I suppose that due to the translation of "file" to "fichier". It's OK when I switch back to - setupstrings    cd:file ==> file You can translate these string because they are only used in the command

...

- variables file ==> file Constants (\c!...) and variables (\v!...) can be changed, only

Garulfo schrieb am 26.06.2020 um 12:27: list to provide the texts which are shown in uppercase letter, e.g. NUMBER. parameters which use the form \s!... have to be english in all cases (saves memory and improves performance).

...

How can I translate the variable "file" into fichier, without messing with fonts (and maybe other file related functions) There shouldn't be a problem with fonts because they use \s!file or \s!name which aren't translated (unless you made the mistake and have \c!file in your typescripts). It's possible there is a bug somewhere but you have to provide a minimal example.

Wolfgang

Garulfo

3:38 p.m.

...

...
So, I'm still doing something wrong, because changing the translation of "figure" in "mult-def.lua" (in the part "variables"), only affect : 1- command "\startfigure \stopfigure" 2- "figure" in "\setuppageinjection" > alternative = figure buffer... You have to provide your modified mult-def.lua file, otherwise there is no way to check what's wrong.

Patch file : mult-def.lua.test1_figure.diff context --make fr context --interface=fr --global --result=setup-fr x-setups-overview.mkiv Then the pdf file shows - \demarrefigurefr as expected (p62) but - \placefigure instead of \placefigurefr (p190) - \demarreplacefigure instead of \demarreplacefigurefr (p72)

...

...
the translation of the variable "itemize" has no impact on the setup-fr.pdf file produced But, I just found that if I actually use the translated commands in a test.tex file, it just works. Same as above, provide your translations.

Patch file : mult-def.lua.test2_itemize.diff Input file : test2_itemize.tex context --make fr context --interface=fr --global --result=setup-fr x-setups-overview.mkiv context test2_itemize.tex setup-fr.pdf shows "\debutitemize ... \finitemize" page 41 instead of "\debutlister ... \finlister" but the input file, with "\debutlister ... \finlister", works great.

...

There shouldn't be a problem with fonts because they use \s!file or \s!name which aren't translated (unless you made the mistake and have \c!file in your typescripts). It's possible there is a bug somewhere but you have to provide a minimal example.

Understood, I am going to check.

Garulfo

4:04 p.m.

...

...
Math. I get the following error :

fonts > preloading latin modern fonts (second stage) fonts > defining > font with asked name 'fichier' is not found using lookup 'file' fonts > defining > unknown font 'fichier', loading aborted

I suppose that due to the translation of "file" to "fichier". It's OK when I switch back to - setupstrings cd:file ==> file You can translate these string because they are only used in the command list to provide the texts which are shown in uppercase letter, e.g. NUMBER. - variables file ==> file Constants (\c!...) and variables (\v!...) can be changed, only parameters which use the form \s!... have to be english in all cases (saves memory and improves performance). How can I translate the variable "file" into fichier, without messing with fonts (and maybe other file related functions) There shouldn't be a problem with fonts because they use \s!file or \s!name which aren't translated (unless you made the mistake and have \c!file in your typescripts). It's possible there is a bug somewhere but you have to provide a minimal example.

My understanding: I translated \setupbodyfont into \configurerfonteprincipale. But I didn't specify any font in the input file. As soon as I specified \configurerfonteprincipale[pagella,10pt] in the input file, font messages "'fichier' is not found" disappear. Is there an additionnal thing to do in order to enable the loading of a default math font, without any font specification, but still with translations of "file" into "fichier" ?

Wolfgang Schuster

27 Jun 27 Jun

4:02 a.m.

Garulfo schrieb am 27.06.2020 um 00:04:

...

...
...
How can I translate the variable "file" into fichier, without messing with fonts (and maybe other file related functions) There shouldn't be a problem with fonts because they use \s!file or \s!name which aren't translated (unless you made the mistake and have \c!file in your typescripts). It's possible there is a bug somewhere but you have to provide a minimal example.

My understanding:

I translated \setupbodyfont into \configurerfonteprincipale.

But I didn't specify any font in the input file.

As soon as I specified vpagella,10pt] in the input file, font messages "'fichier' is not found" disappear.

Is there an additionnal thing to do in order to enable the loading of a default math font, without any font specification, but still with translations of "file" into "fichier" ?

I'm unable to reproduce the error. I added the "configurerfonteprincipale" to mult-def.lua and can use it in your itemize test document without problems. It helps to have a example which produces the error and your complete mult-def.lua file. Also helpful is to add \tracingall (or just \tracingmacros=2) before \configurerfonteprincipale to get more informations what's happening with the command. Wolfgang

Garulfo

11 a.m.

Hi Wolfgang, Did you manage to have a look at the previous message Fri Jun 26 23:38:48 CEST 202023 https://mailman.ntg.nl/pipermail/ntg-context/2020/098596.html It contains two MWE : 1/ mult-def.lua.test1_figure.diff 2/ mult-def.lua.test2_itemize.diff + test2_itemize.tex (not about the font issue, but the two others) Le 27/06/2020 à 12:02, Wolfgang Schuster a écrit :

...

Garulfo schrieb am 27.06.2020 um 00:04:

...
...
...
How can I translate the variable "file" into fichier, without messing with fonts (and maybe other file related functions) There shouldn't be a problem with fonts because they use \s!file or \s!name which aren't translated (unless you made the mistake and have \c!file in your typescripts). It's possible there is a bug somewhere but you have to provide a minimal example.

My understanding:

I translated \setupbodyfont into \configurerfonteprincipale.

But I didn't specify any font in the input file.

As soon as I specified vpagella,10pt] in the input file, font messages "'fichier' is not found" disappear.

Is there an additionnal thing to do in order to enable the loading of a default math font, without any font specification, but still with translations of "file" into "fichier" ?

I'm unable to reproduce the error.

I added the "configurerfonteprincipale" to mult-def.lua and can use it in your itemize test document without problems.

It helps to have a example which produces the error and your complete mult-def.lua file.

Also helpful is to add \tracingall (or just \tracingmacros=2) before \configurerfonteprincipale to get more informations what's happening with the command.

Wolfgang

Wolfgang Schuster

11:16 a.m.

Garulfo schrieb am 27.06.2020 um 19:00:

...

Hi Wolfgang,

Did you manage to have a look at the previous message Fri Jun 26 23:38:48 CEST 202023 https://mailman.ntg.nl/pipermail/ntg-context/2020/098596.html

It contains two MWE :

1/ mult-def.lua.test1_figure.diff

2/ mult-def.lua.test2_itemize.diff + test2_itemize.tex

(not about the font issue, but the two others)

The cause for the missing translations is this line in x-setups-basics.mkiv replace('cd:instances/cd:constant', 'value', variables) which works only when the instances are listed in the command entry like this ... cd:instances which is never the case because I load the entries with cd:resolve like here: ... cd:instances Wolfgang

Garulfo

28 Jun 28 Jun

4:07 p.m.

Do you think it would be easy to change the current behavior ? do you want me to try to propose a workaround ? I am not so familiar with mkiv files, but I can try.

...

Le 27 juin 2020 à 19:16, Wolfgang Schuster a écrit :

Garulfo schrieb am 27.06.2020 um 19:00:

...
Hi Wolfgang,

Did you manage to have a look at the previous message Fri Jun 26 23:38:48 CEST 202023 https://mailman.ntg.nl/pipermail/ntg-context/2020/098596.html

It contains two MWE :

1/ mult-def.lua.test1_figure.diff

2/ mult-def.lua.test2_itemize.diff + test2_itemize.tex

(not about the font issue, but the two others)

The cause for the missing translations is this line in x-setups-basics.mkiv

replace('cd:instances/cd:constant', 'value', variables)

which works only when the instances are listed in the command entry like this

... cd:instances

which is never the case because I load the entries with cd:resolve like here:

... cd:instances

Wolfgang

Garulfo

30 Jun 30 Jun

3:09 p.m.

...

...
The cause for the missing translations is this line in x-setups-basics.mkiv replace('cd:instances/cd:constant', 'value', variables) which works only when the instances are listed in the command entry like this ... cd:instances which is never the case because I load the entries with cd:resolve like here:

... cd:instances

Thanks a lot Wolfgang for the explanations. A remaining question, due to the fact that I am not sure to understand all the implications: Is there some hope to find a solution to also translate the "cd:resolve" entries for the setup-xx.pdf files ? or does it mean that such a request is not compatible with the basic structure of the data / of the translation process ? Thanks again, for your help and for your time.

Wolfgang Schuster

3:53 p.m.

Garulfo schrieb am 30.06.2020 um 23:09:

...

...
...
The cause for the missing translations is this line in x-setups-basics.mkiv replace('cd:instances/cd:constant', 'value', variables) which works only when the instances are listed in the command entry like this ... cd:instances which is never the case because I load the entries with cd:resolve like here:

... cd:instances

Thanks a lot Wolfgang for the explanations.

A remaining question, due to the fact that I am not sure to understand all the implications: Is there some hope to find a solution to also translate the "cd:resolve" entries for the setup-xx.pdf files ? or does it mean that such a request is not compatible with the basic structure of the data / of the translation process ?

Thanks again, for your help and for your time.

You can try to replace the line replace('cd:instances/cd:constant', 'value', variables) with replace('cd:constant', 'value', variables) in x-setups-basics.mkiv and check if this replaces the texts. Wolfgang

Alan Braslau

27 Jun 27 Jun

10:18 a.m.

fonte ? (police) principale ? (corps) ... Alan On 26/06/20 16:04, Garulfo wrote:

...

...
...
Math. I get the following error :

fonts > preloading latin modern fonts (second stage) fonts > defining > font with asked name 'fichier' is not found using lookup 'file' fonts > defining > unknown font 'fichier', loading aborted

I suppose that due to the translation of "file" to "fichier". It's OK when I switch back to - setupstrings cd:file ==> file You can translate these string because they are only used in the command list to provide the texts which are shown in uppercase letter, e.g. NUMBER. - variables file ==> file Constants (\c!...) and variables (\v!...) can be changed, only parameters which use the form \s!... have to be english in all cases (saves memory and improves performance). How can I translate the variable "file" into fichier, without messing with fonts (and maybe other file related functions) There shouldn't be a problem with fonts because they use \s!file or \s!name which aren't translated (unless you made the mistake and have \c!file in your typescripts). It's possible there is a bug somewhere but you have to provide a minimal example.

My understanding:

I translated \setupbodyfont into \configurerfonteprincipale.

But I didn't specify any font in the input file.

As soon as I specified \configurerfonteprincipale[pagella,10pt] in the input file, font messages "'fichier' is not found" disappear.

Is there an additionnal thing to do in order to enable the loading of a default math font, without any font specification, but still with translations of "file" into "fichier" ?

Garulfo

30 Jun 30 Jun

3:02 p.m.

Hi Alan, i will not forget your remark, I don't remember why I get to such a translation. Maybe after working on translation and consistency between these ~2000 keywords... For "corps" and "fonte", it will be easy to change (there is not a lot of tags) If you agree, when I will have something "working", I will submit it to you, in order to get your feedback (just a 10 to 15 minutes overview can enable to catch the major issues) Le 27/06/2020 à 18:18, Alan Braslau a écrit :

...

fonte ? (police) principale ? (corps) ...

Alan

On 26/06/20 16:04, Garulfo wrote:

...
...
...
Math. I get the following error :

fonts > preloading latin modern fonts (second stage) fonts > defining > font with asked name 'fichier' is not found using lookup 'file' fonts > defining > unknown font 'fichier', loading aborted

I suppose that due to the translation of "file" to "fichier". It's OK when I switch back to - setupstrings cd:file ==> file You can translate these string because they are only used in the command list to provide the texts which are shown in uppercase letter, e.g. NUMBER. - variables file ==> file Constants (\c!...) and variables (\v!...) can be changed, only parameters which use the form \s!... have to be english in all cases (saves memory and improves performance). How can I translate the variable "file" into fichier, without messing with fonts (and maybe other file related functions) There shouldn't be a problem with fonts because they use \s!file or \s!name which aren't translated (unless you made the mistake and have \c!file in your typescripts). It's possible there is a bug somewhere but you have to provide a minimal example.

My understanding:

I translated \setupbodyfont into \configurerfonteprincipale.

But I didn't specify any font in the input file.

As soon as I specified \configurerfonteprincipale[pagella,10pt] in the input file, font messages "'fichier' is not found" disappear.

Is there an additionnal thing to do in order to enable the loading of a default math font, without any font specification, but still with translations of "file" into "fichier" ?

1477

Age (days ago)

1481

Last active (days ago)

List overview

Download

11 comments

3 participants

participants (3)

Alan Braslau
Garulfo
Wolfgang Schuster