Re: [Freedos-devel] NLS in Edlin

[Gregory Pietsch via Freedos-devel]

I don't keep track of whether changes had been made, but if someone wants to 
hack it in, be my guest and send me an e-mail. I still have to check on what 
hysterical historical behavior was for this, so I winged it.

Gregory


> On 02/05/2024 4:50 PM EST Jim Hall via Freedos-devel 
>  wrote:
> 
>  
> Not really about internationalization, so I'll make it a separate email:
> 
> 
> Whenever you quit Edlin, you always get this prompt:
> 
> > *q
> > Abort edit (Y/n)? y
> 
> I always find it a little concerning when I've already saved my file
> and Edlin asks if I want to "abort" my edit. It always makes me answer
> "n" and then write the file with "w" anyway before I use "q" again to
> quit. You get the same message with "e" ("end" : write and quit) which
> also makes me feel weird, which is why I prefer "w" then "q" to write
> then quit with individual steps so I know it's been saved.
> 
> So this one is really a suggestion: can we not display "Abort edit
> (Y/n)?" if the file has been saved and no changes made? Or if that
> "change detection" would be too much to add, then maybe don't display
> that message with "e" because the program is supposed to write before
> quitting anyway.
> 
> 
> ___
> Freedos-devel mailing list
> Freedos-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/freedos-devel


___
Freedos-devel mailing list
Freedos-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-devel

Re: [Freedos-devel] NLS in Edlin

[Jim Hall via Freedos-devel]

Not really about internationalization, so I'll make it a separate email:


Whenever you quit Edlin, you always get this prompt:

> *q
> Abort edit (Y/n)? y

I always find it a little concerning when I've already saved my file
and Edlin asks if I want to "abort" my edit. It always makes me answer
"n" and then write the file with "w" anyway before I use "q" again to
quit. You get the same message with "e" ("end" : write and quit) which
also makes me feel weird, which is why I prefer "w" then "q" to write
then quit with individual steps so I know it's been saved.

So this one is really a suggestion: can we not display "Abort edit
(Y/n)?" if the file has been saved and no changes made? Or if that
"change detection" would be too much to add, then maybe don't display
that message with "e" because the program is supposed to write before
quitting anyway.


___
Freedos-devel mailing list
Freedos-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-devel

Re: [Freedos-devel] NLS in Edlin

[Gregory Pietsch via Freedos-devel]

> On 02/05/2024 4:48 PM EST Jim Hall via Freedos-devel 
>  wrote:
> 
>  
> Gregory Pietsch wrote:
> > Believe me, I've had a few headaches over the years regarding NLS. This
> > led to the myriad of ways to do NLS in Edlin. Anyway, all the strings
> > that would need to be translated are #defines in msgs.h, and I included
> > a simple filter program to generate msgs.h files from the NLS files. I
> > don't know if NLS was done the right way from the start (POSIX sus4,
> > anyone?) but you shouldn't have to put a hundred FreeDOS programmers
> > into a room and get 101 ways of doing NLS in a program.
> >
> > Edlin is supposed to be TINY, and I've turned into the guardian of bloat.
> [..]
> 
> I suppose one option is to go the ed(1) route and minimize the output
> it produces. But that starts to tilt dangerously into "user
> aggressive" territory.
> 
> That said, maybe Edlin uses a bit too much text. For example, when you
> start Edlin, it produces this copyright message (which should be
> translated)
> > edlin 2.23, copyright (c) 2003 Gregory Pietsch
> > This program comes with ABSOLUTELY NO WARRANTY.
> > It is free software, and you are welcome to redistribute it
> > under the terms of the GNU General Public License -- either
> > version 2 of the license, or, at your option, any later
> > version.
> >
> > *
> 
> ..where "*" is the prompt.
> 
> Does it need to produce that much text? Or could Edlin just start with
> a "*" prompt?

Normally, that kind of text is produced on a "show version" option. That's 
boilerplate for the GNU license. I wanted to have enough space for translations.

> 
> When you ask for help with "?" Edlin produces this text:
> > *?
> >
> > edlin has the following subcommands:
> >
> > # edit a single line[#],[#],#mmove
> > a append[#][,#]p  page
> > [#],[#],#,[#]ccopy  q quit
> > [#][,#]d  delete[#][,#][?]r$,$replace
> > e<>   end (write & quit)[#][,#][?]s$  search
> > [#]i  insert[#]t<>transfer
> > [#][,#]l  list  [#]w<>write
> >
> > where $ above is a string, <> is a filename,
> > # is a number (which may be .=current line, $=last line,
> > or either number + or - another number).
> 
> I don't know if the first "edlin has the following subcommands" line
> needs to be there. That saves 1 line of translation, which isn't much.
> But every little bit, right?

I wanted the help text to be thorough!

Gregory

> 
> Jim
> 
> 
> ___
> Freedos-devel mailing list
> Freedos-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/freedos-devel


___
Freedos-devel mailing list
Freedos-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-devel

Re: [Freedos-devel] NLS in Edlin

[Jim Hall via Freedos-devel]

Gregory Pietsch wrote:
> Believe me, I've had a few headaches over the years regarding NLS. This
> led to the myriad of ways to do NLS in Edlin. Anyway, all the strings
> that would need to be translated are #defines in msgs.h, and I included
> a simple filter program to generate msgs.h files from the NLS files. I
> don't know if NLS was done the right way from the start (POSIX sus4,
> anyone?) but you shouldn't have to put a hundred FreeDOS programmers
> into a room and get 101 ways of doing NLS in a program.
>
> Edlin is supposed to be TINY, and I've turned into the guardian of bloat.
[..]

I suppose one option is to go the ed(1) route and minimize the output
it produces. But that starts to tilt dangerously into "user
aggressive" territory.

That said, maybe Edlin uses a bit too much text. For example, when you
start Edlin, it produces this copyright message (which should be
translated)
> edlin 2.23, copyright (c) 2003 Gregory Pietsch
> This program comes with ABSOLUTELY NO WARRANTY.
> It is free software, and you are welcome to redistribute it
> under the terms of the GNU General Public License -- either
> version 2 of the license, or, at your option, any later
> version.
>
> *

..where "*" is the prompt.

Does it need to produce that much text? Or could Edlin just start with
a "*" prompt?

When you ask for help with "?" Edlin produces this text:
> *?
>
> edlin has the following subcommands:
>
> # edit a single line[#],[#],#mmove
> a append[#][,#]p  page
> [#],[#],#,[#]ccopy  q quit
> [#][,#]d  delete[#][,#][?]r$,$replace
> e<>   end (write & quit)[#][,#][?]s$  search
> [#]i  insert[#]t<>transfer
> [#][,#]l  list  [#]w<>write
>
> where $ above is a string, <> is a filename,
> # is a number (which may be .=current line, $=last line,
> or either number + or - another number).

I don't know if the first "edlin has the following subcommands" line
needs to be there. That saves 1 line of translation, which isn't much.
But every little bit, right?

Jim


___
Freedos-devel mailing list
Freedos-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-devel

Re: [Freedos-devel] NLS in Edlin

[Gregory Pietsch via Freedos-devel]

Believe me, I've had a few headaches over the years regarding NLS. This led to 
the myriad of ways to do NLS in Edlin. Anyway, all the strings that would need 
to be translated are #defines in msgs.h, and I included a simple filter program 
to generate msgs.h files from the NLS files. I don't know if NLS was done the 
right way from the start (POSIX sus4, anyone?) but you shouldn't have to put a 
hundred FreeDOS programmers into a room and get 101 ways of doing NLS in a 
program.

Edlin is supposed to be TINY, and I've turned into the guardian of bloat. I've 
tried to make it so that someone who is not in the priesthood could easily 
compile the thing with the right compiler, and I've tried to be broad about the 
compiler to use. Instead of tight 80x86 assembler, I made it portable as hell. 
It runs on Linux! It runs on Windows! It runs on Homer Simpson's brain! 
(Maybe...) Someone compiled it on a smartphone! Now I'm ranting

Gregory

> On 02/04/2024 2:55 PM EST Ralf Quint via Freedos-devel 
>  wrote:
> 
>  
> On 2/4/2024 11:32 AM, Jerome Shidel via Freedos-devel wrote:
> > Hi,
> >
> >> On Feb 4, 2024, at 2:16 PM, Ralf Quint via Freedos-devel 
> >>  wrote:
> >>
> >> On 2/4/2024 10:17 AM, Gregory Pietsch via Freedos-devel wrote:
> >>> I made recompiling Edlin easy for non-programmers, so that shouldn't be a 
> >>> problem. You don't have to know a lick of C to recompile it.
> >> Well, part of the problem is that in order to recompile, you need to have 
> >> the compiler (toolchain) installed, which isn't necessarily easy for a 
> >> non-programmer.
> >>
> >>
> >> Ralf
> > I have occasionally compiled edlin to provide an updated version for 
> > FreeDOS.
> >
> > As compile from source goes, EDLIN is not that bad. If I recall correctly, 
> > It just needs our Watcom-C to compile. Plus a little knowledge on options 
> > and such things.
> >
> > In general, it is extremely cumbersome to acquire all the exact required 
> > pieces to accomplish. An fairly often after spending a few hours on trying 
> > to get a successful compile, I will end up giving up. Therefore, I do that 
> > very rarely anymore for almost anything.
> The problem with the whole NLS/i18n thing is that it is not only done 
> with just translating some text extruded from the sources. And 
> recompiling some programs which don't lend themselves well to the whole 
> "kitten" shebang. It would require a lot of testing, which needs to be 
> done by someone with those native language skills (plus some technical 
> knowledge what it is all about). A lot of command line tools might be 
> fairly easy to do, but for anything that is using a more formatted 
> screen output, this also requires to check where things are 
> "overflowing" (for lack of a better term right now)/misalignment...
> And we have a very limited number of people that would have ALL the 
> required skills.
> IMHO, before getting too much wound up with everything that is involved, 
> I think we need to make sure to have a proper English version, for 
> everything,
> >
> > As discussed in the online meeting, it would be nice to include dependency 
> > requirements in the package metadata. This makes me think we could possibly 
> > include the build-dependency requirements as well. Plus a per package 
> > universal build batch. That would be a lot of work and probably require 
> > frequent updating when packages change.
> I see that there would be some effort initially to add that info, but 
> seriously, how much are dependencies as such changing for any given 
> program after that?
> >
> > But on the other hand, it would be very nice if all programs (excluding 
> > those made with commercial compilers like Turbo Pascal) could be built from 
> > source simply by installing the required build packages.
> >
> > This leads me to think, maybe we should go back to the old days when 
> > sources were in their own separate package and not included in the binaries 
> > package.
> >
> That was a move that I have never understood in the first place, as the 
> vast majority of people downloading FreeDOS are likely just interested 
> in getting it running, rather than doing any development. Specially if 
> things aren't as simple anymore as they (mostly) used to be in the days 
> of DOS, too many Linuxisms have crept in, which makes it so much harder 
> for people that are just trying to get back into DOS and haven't done 
> anything programming wise for the last 20-30 years, and then in things 
> like BASIC or Turbo Pascal, which are all "programma  non grata" for a 
> lot of OSS license minded folks...
> 
> 
> Ralf
> 
> 
> 
> ___
> Freedos-devel mailing list
> Freedos-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/freedos-devel


___
Freedos-devel mailing list
Freedos-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-devel

Re: [Freedos-devel] NLS in Edlin

[Jerome Shidel via Freedos-devel]

Ralf,

> On Feb 4, 2024, at 2:55 PM, Ralf Quint via Freedos-devel 
>  wrote:
> 
> On 2/4/2024 11:32 AM, Jerome Shidel via Freedos-devel wrote:
>> Hi,
>> 
>>> On Feb 4, 2024, at 2:16 PM, Ralf Quint via Freedos-devel 
>>>  wrote:
>>> 
>>> On 2/4/2024 10:17 AM, Gregory Pietsch via Freedos-devel wrote:
 I made recompiling Edlin easy for non-programmers, so that shouldn't be a 
 problem. You don't have to know a lick of C to recompile it.
>>> Well, part of the problem is that in order to recompile, you need to have 
>>> the compiler (toolchain) installed, which isn't necessarily easy for a 
>>> non-programmer.
>>> 
>>> 
>>> Ralf
>> I have occasionally compiled edlin to provide an updated version for FreeDOS.
>> 
>> As compile from source goes, EDLIN is not that bad. If I recall correctly, 
>> It just needs our Watcom-C to compile. Plus a little knowledge on options 
>> and such things.
>> 
>> In general, it is extremely cumbersome to acquire all the exact required 
>> pieces to accomplish. An fairly often after spending a few hours on trying 
>> to get a successful compile, I will end up giving up. Therefore, I do that 
>> very rarely anymore for almost anything.
> The problem with the whole NLS/i18n thing is that it is not only done with 
> just translating some text extruded from the sources. And recompiling some 
> programs which don't lend themselves well to the whole "kitten" shebang. It 
> would require a lot of testing, which needs to be done by someone with those 
> native language skills (plus some technical knowledge what it is all about). 
> A lot of command line tools might be fairly easy to do, but for anything that 
> is using a more formatted screen output, this also requires to check where 
> things are "overflowing" (for lack of a better term right now)/misalignment…

Yup. 

> And we have a very limited number of people that would have ALL the required 
> skills.

Yup. 

> IMHO, before getting too much wound up with everything that is involved, I 
> think we need to make sure to have a proper English version, for everything,

Yup. 

>> 
>> As discussed in the online meeting, it would be nice to include dependency 
>> requirements in the package metadata. This makes me think we could possibly 
>> include the build-dependency requirements as well. Plus a per package 
>> universal build batch. That would be a lot of work and probably require 
>> frequent updating when packages change.
> I see that there would be some effort initially to add that info, but 
> seriously, how much are dependencies as such changing for any given program 
> after that?

For small projects, not usually much changes or very often. 

On the other hand for large projects, sometimes different libraries come and 
go. But generally, the problem with these are based on specific versions of 
libraries. Or, sub-dependency libraries and their versions. 

However, I only extremely rarely make the exception and compile projects we 
distribute from source. So, the problem may not be as bad as I suspect.

>> 
>> But on the other hand, it would be very nice if all programs (excluding 
>> those made with commercial compilers like Turbo Pascal) could be built from 
>> source simply by installing the required build packages.
>> 
>> This leads me to think, maybe we should go back to the old days when sources 
>> were in their own separate package and not included in the binaries package.
>> 
> That was a move that I have never understood in the first place, as the vast 
> majority of people downloading FreeDOS are likely just interested in getting 
> it running, rather than doing any development. Specially if things aren't as 
> simple anymore as they (mostly) used to be in the days of DOS, too many 
> Linuxisms have crept in, which makes it so much harder for people that are 
> just trying to get back into DOS and haven't done anything programming wise 
> for the last 20-30 years, and then in things like BASIC or Turbo Pascal, 
> which are all "programma  non grata" for a lot of OSS license minded folks…

Furthermore, if the packages were split back into BIN and SRCS, we could 
provide the sources on a separate media. This could possibly cut the size of 
the release media in half. Maybe even alleviate the need for a BonusCD. 
Possibly just the LiveCD, LegacyCD and a SourcesCD. 

Change back to the split packages would require some tweaking to the installer 
and RBE. Probably FDIMPLES as well. Nothing to difficult. 

The online package repo management software used on ibiblio and fd.lod.bz is 
not designed for it. But, those places could just keep using the combined 
packages until I get around to making the next version of the repository 
management utilities. 


> Ralf

:-)

Jerome


> ___
> Freedos-devel mailing list
> Freedos-devel@lists.sourceforge.net 
> 
> https://lists.sourceforge.net/lists/listinfo/freedos-devel 
> 

Re: [Freedos-devel] NLS in Edlin

[Ralf Quint via Freedos-devel]

On 2/4/2024 11:32 AM, Jerome Shidel via Freedos-devel wrote:

Hi,


On Feb 4, 2024, at 2:16 PM, Ralf Quint via Freedos-devel 
 wrote:

On 2/4/2024 10:17 AM, Gregory Pietsch via Freedos-devel wrote:

I made recompiling Edlin easy for non-programmers, so that shouldn't be a 
problem. You don't have to know a lick of C to recompile it.

Well, part of the problem is that in order to recompile, you need to have the 
compiler (toolchain) installed, which isn't necessarily easy for a 
non-programmer.


Ralf

I have occasionally compiled edlin to provide an updated version for FreeDOS.

As compile from source goes, EDLIN is not that bad. If I recall correctly, It 
just needs our Watcom-C to compile. Plus a little knowledge on options and such 
things.

In general, it is extremely cumbersome to acquire all the exact required pieces 
to accomplish. An fairly often after spending a few hours on trying to get a 
successful compile, I will end up giving up. Therefore, I do that very rarely 
anymore for almost anything.
The problem with the whole NLS/i18n thing is that it is not only done 
with just translating some text extruded from the sources. And 
recompiling some programs which don't lend themselves well to the whole 
"kitten" shebang. It would require a lot of testing, which needs to be 
done by someone with those native language skills (plus some technical 
knowledge what it is all about). A lot of command line tools might be 
fairly easy to do, but for anything that is using a more formatted 
screen output, this also requires to check where things are 
"overflowing" (for lack of a better term right now)/misalignment...
And we have a very limited number of people that would have ALL the 
required skills.
IMHO, before getting too much wound up with everything that is involved, 
I think we need to make sure to have a proper English version, for 
everything,


As discussed in the online meeting, it would be nice to include dependency 
requirements in the package metadata. This makes me think we could possibly 
include the build-dependency requirements as well. Plus a per package universal 
build batch. That would be a lot of work and probably require frequent updating 
when packages change.
I see that there would be some effort initially to add that info, but 
seriously, how much are dependencies as such changing for any given 
program after that?


But on the other hand, it would be very nice if all programs (excluding those 
made with commercial compilers like Turbo Pascal) could be built from source 
simply by installing the required build packages.

This leads me to think, maybe we should go back to the old days when sources 
were in their own separate package and not included in the binaries package.

That was a move that I have never understood in the first place, as the 
vast majority of people downloading FreeDOS are likely just interested 
in getting it running, rather than doing any development. Specially if 
things aren't as simple anymore as they (mostly) used to be in the days 
of DOS, too many Linuxisms have crept in, which makes it so much harder 
for people that are just trying to get back into DOS and haven't done 
anything programming wise for the last 20-30 years, and then in things 
like BASIC or Turbo Pascal, which are all "programma  non grata" for a 
lot of OSS license minded folks...



Ralf



___
Freedos-devel mailing list
Freedos-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-devel

Re: [Freedos-devel] NLS in Edlin

[Jerome Shidel via Freedos-devel]

Hi, 

> On Feb 4, 2024, at 2:16 PM, Ralf Quint via Freedos-devel 
>  wrote:
> 
> On 2/4/2024 10:17 AM, Gregory Pietsch via Freedos-devel wrote:
>> I made recompiling Edlin easy for non-programmers, so that shouldn't be a 
>> problem. You don't have to know a lick of C to recompile it.
> 
> Well, part of the problem is that in order to recompile, you need to have the 
> compiler (toolchain) installed, which isn't necessarily easy for a 
> non-programmer.
> 
> 
> Ralf

I have occasionally compiled edlin to provide an updated version for FreeDOS. 

As compile from source goes, EDLIN is not that bad. If I recall correctly, It 
just needs our Watcom-C to compile. Plus a little knowledge on options and such 
things. 

In general, it is extremely cumbersome to acquire all the exact required pieces 
to accomplish. An fairly often after spending a few hours on trying to get a 
successful compile, I will end up giving up. Therefore, I do that very rarely 
anymore for almost anything.

As discussed in the online meeting, it would be nice to include dependency 
requirements in the package metadata. This makes me think we could possibly 
include the build-dependency requirements as well. Plus a per package universal 
build batch. That would be a lot of work and probably require frequent updating 
when packages change. 

But on the other hand, it would be very nice if all programs (excluding those 
made with commercial compilers like Turbo Pascal) could be built from source 
simply by installing the required build packages.

This leads me to think, maybe we should go back to the old days when sources 
were in their own separate package and not included in the binaries package. 

Jerome




___
Freedos-devel mailing list
Freedos-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-devel

Re: [Freedos-devel] NLS in Edlin

[Ralf Quint via Freedos-devel]

On 2/4/2024 10:17 AM, Gregory Pietsch via Freedos-devel wrote:

I made recompiling Edlin easy for non-programmers, so that shouldn't be a 
problem. You don't have to know a lick of C to recompile it.


Well, part of the problem is that in order to recompile, you need to 
have the compiler (toolchain) installed, which isn't necessarily easy 
for a non-programmer.



Ralf




___
Freedos-devel mailing list
Freedos-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-devel

Re: [Freedos-devel] NLS in Edlin

[Gregory Pietsch via Freedos-devel]

I tried to make Edlin portable enough so that multiple toolchains would work on 
it. I normally use Cygwin with GCC and make to compile it, but FreeDOS is a 
DOS, so I tried to make it so that multiple compilers could compile it. Forgive 
my wording here...

Anyway, tweaking config.h should take care of the differences in compilers. 
That file can also be generated through the configure script (as well as the 
makefile), but DOS wants things as simple as they can be. ;-)

The files edlin.en and msgs-en.h in the distro are the English-language 
versions of the catalog and msgs.h, respectively.

If I submitted a set of files for every language and compiler in existence, the 
politics of multiplication would come in, and I would be old and grey (or 
possibly dead from old age) before that project would be completed.

Gregory

> On 02/04/2024 1:32 PM EST Eric Auer  wrote:
> 
>  
> > I made recompiling Edlin easy for non-programmers,
> > so that shouldn't be a problem. You don't have to
> > know a lick of C to recompile it.
> 
> One would still need the toolchain, so it would
> be great if there could be somebody who already
> has it (and does know C, just in case) who would
> volunteer as the "send me your NLS updates for
> EDLIN and I will make sure an updated EDLIN zip
> will get published" person. Or, as said, a CI way.
> 
> Eric
> 
> PS: As mentioned on BTTR in the Book8088 compat thread
> (which found out that SYS CONFIG GLOBALENABLELBASUPPORT=0
> can work around some crash in XT-IDE BIOS!) even seemingly
> easy to use compiles fail in *unexpected* ways, e.g. OW
> 2.0 compiles kernels in Linux, but only 1.9 does in DOS?


___
Freedos-devel mailing list
Freedos-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-devel

Re: [Freedos-devel] NLS in Edlin

[Eric Auer via Freedos-devel]

I made recompiling Edlin easy for non-programmers,
so that shouldn't be a problem. You don't have to
know a lick of C to recompile it.


One would still need the toolchain, so it would
be great if there could be somebody who already
has it (and does know C, just in case) who would
volunteer as the "send me your NLS updates for
EDLIN and I will make sure an updated EDLIN zip
will get published" person. Or, as said, a CI way.

Eric

PS: As mentioned on BTTR in the Book8088 compat thread
(which found out that SYS CONFIG GLOBALENABLELBASUPPORT=0
can work around some crash in XT-IDE BIOS!) even seemingly
easy to use compiles fail in *unexpected* ways, e.g. OW
2.0 compiles kernels in Linux, but only 1.9 does in DOS?




___
Freedos-devel mailing list
Freedos-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-devel

Re: [Freedos-devel] NLS in Edlin

[Gregory Pietsch via Freedos-devel]

I made recompiling Edlin easy for non-programmers, so that shouldn't be a 
problem. You don't have to know a lick of C to recompile it.

Gregory

> On 02/04/2024 12:59 PM EST Eric Auer via Freedos-devel 
>  wrote:
> 
>  
> Hi!
> 
> > Willi Spiegl said in the meeting that there is no NLS in Edlin. I beg to 
> > differ!
> 
> As with the HTMLHELP versus AMB issue, the problem, as far as
> I have understood Willi, is the lack of a process, possibly
> an automated pipeline, which will take updated translations
> and spread them to the right places. As a non-programmer, he
> would not recompile EDLIN to submit updated translations, so
> we have to figure out whom and how to give the files so the
> updates get published to the right, easy to use places :-)
> 
> Eric
> 
> PS: The same probably applies to CTMOUSE and similar tools
> with compile time translations. Could be put into continuous
> integration pipelines, but then updates are rather rare here.
> 
> 
> 
> 
> ___
> Freedos-devel mailing list
> Freedos-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/freedos-devel


___
Freedos-devel mailing list
Freedos-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-devel

Re: [Freedos-devel] NLS in Edlin

[Eric Auer via Freedos-devel]

Hi!


Willi Spiegl said in the meeting that there is no NLS in Edlin. I beg to differ!


As with the HTMLHELP versus AMB issue, the problem, as far as
I have understood Willi, is the lack of a process, possibly
an automated pipeline, which will take updated translations
and spread them to the right places. As a non-programmer, he
would not recompile EDLIN to submit updated translations, so
we have to figure out whom and how to give the files so the
updates get published to the right, easy to use places :-)

Eric

PS: The same probably applies to CTMOUSE and similar tools
with compile time translations. Could be put into continuous
integration pipelines, but then updates are rather rare here.




___
Freedos-devel mailing list
Freedos-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-devel

[Freedos-devel] NLS in Edlin

[Gregory Pietsch via Freedos-devel]

Willi Spiegl said in the meeting that there is no NLS in Edlin. I beg to differ!
 
There are two different ways of supporting NLS in Edlin. The first (easy) way 
is that in the source code, all the message strings are in a file called 
msgs.h, so by translating the strings, putting the translations in a msgs.h 
file, and recompiling, you have a version of Edlin with translated strings. 
When I discovered how the rest of FreeDOS was doing NLS, I put a small program 
in the Edlin distribution called kit2msgs that translated a message catalog 
into a msgs.h file with a minimum of fuss. So, to translate all the messages to 
German, just download edlin.de from Github, add the three new missing messages, 
use kit2msgs to translate that into a msgs.h file, and compile! WAY TOO EASY! 
 
The second way was to read the message catalogs in real time. There's a file 
called msgscats.h in the Edlin source that uses catgets to get the messages, so 
using that as msgs.h and compiling in catgets.c should also work. This is a bag 
on the side of Edlin, and to keep Edlin as small as possible, I don't recommend 
this way, but it's doable. This needs more debugging, though. I tried to write 
a version of catgets that follows the POSIX specifications and uses the same 
format of files as FreeDOS and fits in with the string functionality that the 
rest of Edlin uses, but I could use some feedback.
 
Hopefully this clarifies things.
 
Gregory (not George) Pietsch___
Freedos-devel mailing list
Freedos-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-devel