Re: Update TODO list

[Pavel Roskin <proski gnu org>]

Hi, David!

> Now that we have the 4.6.0 it's time to plain future work.

Right.  I think the development should stay on the 4.6 branch for a while.
There are many rather simple things to be done, and having separate
branches would increase the load on the developers and the time from a
patch to the stable release that includes it.

Once we need to do anything serious that may need more than a month for
stabilization, the 4.6 branch will be created for stable releases, while
the development will be done on the head.  I hope to release at least
4.6.1 before we come to that point, although I'm getting increasingly busy
with my job and personal life, which means that the project will be more
dependent on contributions by other developers.

> I would propose a couple of things...
>
> 1) It's about time to make ftp to sites like ftp.mcafee.com. If other
> programs can why do we not?

Which programs can do it?  I looked at the output of the "ls" command, and
it looks like that handling such a different format would require a very
advanced parser.  At least remote_is_amiga shouldn't be the only site
specific flag.

Also, the complexity of the code may require a testsuite, i.e. emulators
of different sites, so that whoever changes the code could easily check it
for regressions.

> 2) l10n is nearly there, which is great as this is like a
> huge puzzle. We should think of some way to have the user menu
> (the stock entries) translated.

I've been thinking about this.  If we make separate menu files and keep
them on CVS, it will be hard to keep the default menu in sync.

We could make the menu a script that would generate the actual menu at the
runtime using its arguments (current file, current directory, presence of
certain files).  Python is already supported by gettext, but that would be
an additional requirement for mc.  Perl support is planned.

The simplest solution would be to create a C file with all translatable
texts used in the default menu.  That file should be listed in
po/POTFILES.in but not compiled.  mc will translate menu entries on the
fly when they are about to be displayed.  Non-standard entries won't be
translated, which is not good if there are users with different language
preferences on the same machine.

Another possibility would be to generate the menu files in all supported
languages at the compile time.  The source would have all the strings and
would be listed in po/POTFILES.in.  The menu file will be selected at the
runtime based on the locale.

-- 
Regards,
Pavel Roskin