🚀 go-pugleaf

The discussion on the topic of intellectual property has entered a lull.
I thought that I would post an idea that I haven't seen mentioned here.

The GNU software project has many goals.  One goal is to allow programmers
to be creative without assistance or interference from lawyers.  The GNU
project creates legally unencumbered software.  A second goal is to promote
the sharing of source code to encourage code reuse.  The GNU software
license teaches users to expect to get source code of their software.
A third goal is to provide a structure within which many people can make
contributions towards a common goal.  The number of people committed to
making GNU succeed increases each time the FSF announces the availability
of a new piece of software, or distributes a bug fix submitted by a user.

In the long run I expect to see radically new software created.  This will
be possible because the FSF has made available a high quality, complete
software development environment.  What might the new software consist of?

GNU software includes an editor, a compiler, a debugger, and a source code
control system.  Starting with these, it might be possible to synthesize a
programming environment which allows native language editing of software.

For instance a french speaking person might edit an image of some piece of
software using french identifiers and french strings.  The changes to the
code could be understood in a language independent fashion, and merged into
an all-language version of the source.

Are there problems with this idea?  Automatic translation is obviously out.
In order to make this thing work I think people would have to be involved
in two places: in translation and in reconciliation.

Here is what might be necessary.  Software would originally be written in
some single human language.  The source would be parsed and the structure
of the program would be separated from the words describing the program.

The source control system would have to manage program strings, comments,
identifiers including scope information, and intentionally different versions
of code that are different because of particular human language translations.

An editing system would allow a bilingual person to give the system extra
information to effect a translation from the original language to another.
A new type of diff file which would add a translation of a program to the
source code database would have to be developed.

There might be conventions for identifiers, Like_Underscores_Between_Words,
which make it easier to translate identifiers for someone not fluent in the
original language.  Individual words between underscores might have been
used elsewhere in the original software, and the previous translation could
be suggested by the editing system.

There would have to be a plan to allow words which were not yet translated.
Something like English_Original_Identifier might appear in the translation
to some second language if Original_Identifier had not been translated.

If source code never changing, it would be easy to make a translation. I
expect that changes by many people fluent in many languages will occur to
much of the GNU software.  There must be some way to merge the changes.

A german speaker might for instance make changes to a german translation of
a program.  The source code management system would have to compare the new
german source with the original one.  Some changes would only involve the
structure of the program, and would be instantly applicable to the original
source of the program.

When identifiers or strings change, or where a change falls inside code that
has been intentionally modified to express something in a particular human
language, a person will have to intervene.  I can imagine that it would be
the responsibility of the person modifying the code to do the translation
back to the original language before submitting the change to the FSF for
inclusion in the officially current source.

Changes to calls to printf and it's relatives would have to have special
attention.  If arguments are added or removed without changing the format
string in each language, you could get core-dumps in one language and not
in another.  The system should try to understand format strings.

It might be possible to have a single executable with strings used for IO
chosen by a command line switch or environment variable.  The mac and some
new window managers have this ability.  I think that this would need a
replacement for printf and relatives which would have to be able to choose
between a set of strings at run time.  Every place that a program uses
strings would have to be modified to take into account a selection between
languages.  Some of this effort might be hidden by the system which manages
translations.  The system might make available a string type which looks
ordinary to a person editing in any particular language, but which includes
in the source all translations of strings to be consumed by the compiler.

Well that is my idea.  I should like someday to see a multi-language version
of the source to GCC, done within an easy-to-use code management system.
Making possible native-language contributions to the GNU software collection
would increase the number of contributers.  The GNU effort will simplify
international cooperation in software development.  Another GNU goal?

				Lawrence