tcl-core — Tcl Core Team discussions about Tcl development

[TCLCORE] Re: [TCLCORE] Welcome!

[Mo D. <md...@cy...>]

Wasting no time, mo submits a patch for approval.

Mo DeJong
Red Hat Inc

Index: ChangeLog
===================================================================
RCS file: /cvsroot/tk/ChangeLog,v
retrieving revision 1.167
diff -u -r1.167 ChangeLog
--- ChangeLog	2000/06/30 20:33:44	1.167
+++ ChangeLog	2000/07/06 01:03:27
@@ -1,3 +1,19 @@
+2000-07-05  Mo DeJong  <md...@re...>
+
+	* generic/tkFileFilter.c (AddClause): Cast to match function prototype.
+	* win/stubs.c (_XInitImageFuncPtrs): Add return value for function.
+	* win/tkWinButton.c (buttonStyles, ButtonBindProc, ComputeStyle):
+	Remove unused declarations.
+	* win/tkWinColor.c (GetColorByName, GetColorByValue): Remove unused
+	function declarations.
+	* win/tkWinDialog.c (TrySetDirectory): Remove unused function declaration.
+	* win/tkWinEmbed.c (TkWinEmbeddedEventProc): Cast to match 
function prototype.
+	* win/tkWinMenu.c (winMenuMutex, MenuExitProc): Remove unused declaration.
+	* win/tkWinWindow.c (StackWindow): Remove unused declaration.
+	* win/tkWinWm.c (ConfigureEvent): Remove unused declaration.
+	* win/tkWinX.c (winXMutex): Remove unused declaration.
+	* xlib/ximage.c (XCreateBitmapFromData): Cast to match function prototype.
+
 2000-06-30  Eric Melski  <er...@sc...>
 
 	* doc/keysyms.n:
Index: generic/tkFileFilter.c
===================================================================
RCS file: /cvsroot/tk/generic/tkFileFilter.c,v
retrieving revision 1.3
diff -u -r1.3 tkFileFilter.c
--- tkFileFilter.c	1999/04/16 01:51:13	1.3
+++ tkFileFilter.c	2000/07/06 00:59:40
@@ -270,7 +270,7 @@
 		/*
 		 * Prepend a "*" to patterns that do not have a leading "*"
 		 */
-		globPtr->pattern = (char*)ckalloc(len+1);
+		globPtr->pattern = (char*)ckalloc((unsigned int) len+1);
 		globPtr->pattern[0] = '*';
 		strcpy(globPtr->pattern+1, globList[i]);
 	    }
@@ -289,11 +289,11 @@
 		    strcpy(globPtr->pattern, "*.");
 		}
 		else {
-		    globPtr->pattern = (char*)ckalloc(len);
+		    globPtr->pattern = (char*)ckalloc((unsigned int) len);
 		    strcpy(globPtr->pattern, globList[i]);
 		}
 	    } else {
-		globPtr->pattern = (char*)ckalloc(len);
+		globPtr->pattern = (char*)ckalloc((unsigned int) len);
 		strcpy(globPtr->pattern, globList[i]);
 	    }
Index: win/stubs.c
===================================================================
RCS file: /cvsroot/tk/win/stubs.c,v
retrieving revision 1.2
diff -u -r1.2 stubs.c
--- stubs.c	1999/06/16 20:11:30	1.2
+++ stubs.c	2000/07/06 00:59:42
@@ -4,7 +4,7 @@
  * Undocumented Xlib internal function
  */
 
-_XInitImageFuncPtrs(XImage *image)
+int _XInitImageFuncPtrs(XImage *image)
 {
     return 0;
 }
Index: win/tkWinButton.c
===================================================================
RCS file: /cvsroot/tk/win/tkWinButton.c,v
retrieving revision 1.9
diff -u -r1.9 tkWinButton.c
--- tkWinButton.c	2000/05/17 21:17:22	1.9
+++ tkWinButton.c	2000/07/06 00:59:42
@@ -25,10 +25,6 @@
 #define CHECK_STYLE (BS_OWNERDRAW | BS_CHECKBOX | WS_CHILD | WS_VISIBLE 
| WS_CLIPSIBLINGS)
 #define RADIO_STYLE (BS_OWNERDRAW | BS_RADIOBUTTON | WS_CHILD | 
WS_VISIBLE | WS_CLIPSIBLINGS)
 
-static DWORD buttonStyles[] = {
-    LABEL_STYLE, PUSH_STYLE, CHECK_STYLE, RADIO_STYLE
-};
-
 /*
  * Declaration of Windows specific button structure.
  */
@@ -83,13 +79,8 @@
 /*
  * Declarations for functions defined in this file.
  */
-
-static int		ButtonBindProc _ANSI_ARGS_((ClientData clientData,
-			    Tcl_Interp *interp, XEvent *eventPtr,
-			    Tk_Window tkwin, KeySym keySym));
 static LRESULT CALLBACK	ButtonProc _ANSI_ARGS_((HWND hwnd, UINT message,
 			    WPARAM wParam, LPARAM lParam));
-static DWORD		ComputeStyle _ANSI_ARGS_((WinButton* butPtr));
 static Window		CreateProc _ANSI_ARGS_((Tk_Window tkwin,
 			    Window parent, ClientData instanceData));
 static void		InitBoxes _ANSI_ARGS_((void));
Index: win/tkWinColor.c
===================================================================
RCS file: /cvsroot/tk/win/tkWinColor.c,v
retrieving revision 1.5
diff -u -r1.5 tkWinColor.c
--- tkWinColor.c	2000/04/17 06:26:09	1.5
+++ tkWinColor.c	2000/07/06 00:59:42
@@ -80,8 +80,6 @@
 
 static int	FindSystemColor _ANSI_ARGS_((const char *name,
 		    XColor *colorPtr, int *indexPtr));
-static int	GetColorByName _ANSI_ARGS_((char *name, XColor *color));
-static int	GetColorByValue _ANSI_ARGS_((char *value, XColor *color));
 
 /*
  *----------------------------------------------------------------------
Index: win/tkWinDialog.c
===================================================================
RCS file: /cvsroot/tk/win/tkWinDialog.c,v
retrieving revision 1.12
diff -u -r1.12 tkWinDialog.c
--- tkWinDialog.c	2000/06/15 16:01:04	1.12
+++ tkWinDialog.c	2000/07/06 00:59:42
@@ -123,7 +123,6 @@
 static UINT APIENTRY	OFNHookProcW(HWND hdlg, UINT uMsg, WPARAM wParam, 
 			    LPARAM lParam);
 static void		SetTkDialog(ClientData clientData);
-static int		TrySetDirectory(HWND hwnd, const TCHAR *dir);
 
 /*
  *-------------------------------------------------------------------------
Index: win/tkWinEmbed.c
===================================================================
RCS file: /cvsroot/tk/win/tkWinEmbed.c,v
retrieving revision 1.3
diff -u -r1.3 tkWinEmbed.c
--- tkWinEmbed.c	1999/04/16 01:51:51	1.3
+++ tkWinEmbed.c	2000/07/06 00:59:42
@@ -397,7 +397,7 @@
 
 	break;
       case TK_GEOMETRYREQ:
-	EmbedGeometryRequest(containerPtr, wParam, lParam);
+	EmbedGeometryRequest(containerPtr, (int) wParam, lParam);
 	break;
     }
     return 1;
Index: win/tkWinMenu.c
===================================================================
RCS file: /cvsroot/tk/win/tkWinMenu.c,v
retrieving revision 1.10
diff -u -r1.10 tkWinMenu.c
--- tkWinMenu.c	2000/05/16 17:57:32	1.10
+++ tkWinMenu.c	2000/07/06 00:59:42
@@ -82,8 +82,6 @@
 static Tcl_DString menuFontDString;
 				/* A buffer to store the default menu font
 				 * string. */
-TCL_DECLARE_MUTEX(winMenuMutex)
-
 /*
  * Forward declarations for procedures defined later in this file:
  */
@@ -149,7 +147,6 @@
 			    int *heightPtr));
 static int		GetNewID _ANSI_ARGS_((TkMenuEntry *mePtr,
 			    int *menuIDPtr));
-static void		MenuExitProc _ANSI_ARGS_((ClientData clientData));
 static int		MenuKeyBindProc _ANSI_ARGS_((
 			    ClientData clientData, 
 			    Tcl_Interp *interp, XEvent *eventPtr,
Index: win/tkWinWindow.c
===================================================================
RCS file: /cvsroot/tk/win/tkWinWindow.c,v
retrieving revision 1.5
diff -u -r1.5 tkWinWindow.c
--- tkWinWindow.c	1999/04/16 01:51:54	1.5
+++ tkWinWindow.c	2000/07/06 00:59:42
@@ -27,8 +27,6 @@
 
 static void		NotifyVisibility _ANSI_ARGS_((XEvent *eventPtr,
 			    TkWindow *winPtr));
-static void 		StackWindow _ANSI_ARGS_((Window w, Window sibling,
-			    int stack_mode));
 
 /*
  *----------------------------------------------------------------------
Index: win/tkWinWm.c
===================================================================
RCS file: /cvsroot/tk/win/tkWinWm.c,v
retrieving revision 1.25
diff -u -r1.25 tkWinWm.c
--- tkWinWm.c	2000/05/16 00:00:29	1.25
+++ tkWinWm.c	2000/07/06 00:59:43
@@ -276,8 +276,6 @@
 
 static int		ActivateWindow _ANSI_ARGS_((Tcl_Event *evPtr,
 			    int flags));
-static void		ConfigureEvent _ANSI_ARGS_((TkWindow *winPtr,
-			    XConfigureEvent *eventPtr));
 static void		ConfigureTopLevel _ANSI_ARGS_((WINDOWPOS *pos));
 static void		GenerateConfigureNotify _ANSI_ARGS_((
 			    TkWindow *winPtr));
Index: win/tkWinX.c
===================================================================
RCS file: /cvsroot/tk/win/tkWinX.c,v
retrieving revision 1.10
diff -u -r1.10 tkWinX.c
--- tkWinX.c	2000/04/19 01:06:51	1.10
+++ tkWinX.c	2000/07/06 00:59:43
@@ -31,8 +31,6 @@
 static WNDCLASS childClass;	    /* Window class for child windows. */
 static int tkPlatformId;	    /* version of Windows platform */
 
-TCL_DECLARE_MUTEX(winXMutex)
-
 /*
  * Thread local storage.  Notice that now each thread must have its
  * own TkDisplay structure, since this structure contains most of
Index: xlib/ximage.c
===================================================================
RCS file: /cvsroot/tk/xlib/ximage.c,v
retrieving revision 1.3
diff -u -r1.3 ximage.c
--- ximage.c	1998/09/14 18:24:03	1.3
+++ ximage.c	2000/07/06 00:59:43
@@ -47,7 +47,7 @@
     GC gc;
     Pixmap pix;
 
-    pix = Tk_GetPixmap(display, d, width, height, 1);
+    pix = Tk_GetPixmap(display, d, (int) width, (int) height, 1);
     gc = XCreateGC(display, pix, 0, NULL);
     if (gc == NULL) {
 	return None;

--
The TclCore mailing list is sponsored by Ajuba Solutions
To unsubscribe:  email tcl...@aj... with the 
                 word UNSUBSCRIBE as the subject.

[TCLCORE] Welcome!

[Eric M. <er...@aj...>]

Welcome to the tc...@aj... mailing list.  This list is for
people who have CVS write access to the Tcl core repository.  All messages
to this list should have the text "[TCLCORE]" at the start of the subject
line, for easy filtering.  Jeff says, "We're cementing the policies now,"
(with regard to feature changes, etc) and, "Eric is going to get around to
publishing those sometime."  Welcome to the new world order.

   Eric Melski                            The Other Tcl Guy
   ericm at ajubasolutions.com            Ajuba Solutions

--
The TclCore mailing list is sponsored by Ajuba Solutions
To unsubscribe:  email tcl...@aj... with the 
                 word UNSUBSCRIBE as the subject.

Re: Translation messages file

[<lau...@uf...>]

On  4 Jul, Keiichi Takahashi wrote:
> Hi,
> 
> Thank you for your kind information, Laurent.
> 
> Fortunately I've already obtained updated source from CVS repository when I
> received your previous message, and checked it works. But as I mentioned before,
> the issue of 'underline' is serious in order to add the file of Japanese message
> in lib/tk8.4/msgs.
> 
> For message of Japanese version, I think it better to wait until '&' can be used
> to indicate underlined character.
> 
> Or, is this already available?
> 

No it isn't available yet. I've started working on it but I'm segfaulting
all over the place. And it's a bit more involved than I originally expected.

For those who weren't involved in the discussions, the -underline option
causes problems when you change languages; key bindings become a problem
also. A few solutions have been put forward for both of these problems and
I'm looking at the best way to implement it. 

Mr. Takahashi has proposed using the "&" character to mark the location of
the character to underline and to use -underline & as a special case to
locate it. There have been other proposals (which I would need to dig up in
my voluminous email) but this one seems to be the better one IMO. But it
requires modifying the core structure of the Button widget. There's also a
display issue because the "&" needs to disappear from the string, etc.

How this relates to the binding issue is that the underlined character is
the one that should be used in the key binding for the dialog being used.
There have been some discussions on how to best do the binding. Eric
proposed expanding msgcat to handle the keybindings. I'm lukewarm to the
idea. I wanted to "translate" the key bindings from one language to next by
using special names for the key bindings. Something like:

bind [::msgcat::mc "chooseDirOpenDirectoryKey"] {...}

Eric doesn't like the idea.

.
.
.

Maybe something like

set string [$widget cget -text]
set char [indexOfUnderlineInWidget $string]
bind <Alt-$char> {....}

is another viable alternative. IOW, the binding key to use is returned by
the widget which has the underlined character.

If anyone has any other comments, suggestions, let'em rip. Remember that
it's a holiday in the US so we shouldn't expect anything from the TCT before
tomorrow.

L

-- 
Laurent Duperval                   "Montreal winters are an intelligence test,
U|Force - Java Center                     and we who are here have failed it."
Phone: (514) 282-8484 ext. 228                                   -Doug Camilli
mailto:lau...@uf...      Penguin Power!

Translations strings in CVS

[<lau...@uf...>]

Hi all,

The translations strings have all been added to CVS by Eric Melski. If you
haven't done so already, you can check out that Tcl and the Tk tree (the
msgcat package has been modified in Tcl). For those of you who have already
translated strings, there is only one minor addition: "Select Multiple
Files". 

You will also notice the the format of the strings has changed. They've been
generated with the msgedit package, which saves strings in UTF-8 (or
whatever) format. I dont think you absolutely need to use it, but it
generates more portable strings. You can find msgedit at

http://www.tu-harburg.de/~skfcz/msgedit.tar.gz

There is a bug with the program, though: some of the strings contain "\n"'s
and msgedit saves these strings as "\\n". The saved files will need to be
edited to correct this problem.

You can send the translated strings directly to me or to tclcore (cc me if
you do).

The next step is to fix the -underline options and the key bindings. A
number of suggestions have been made (with a preference, it seems, for using
the magic & character) but nothing has been implemented yet.

L

-- 
Laurent Duperval                   "Montreal winters are an intelligence test,
U|Force - Java Center                     and we who are here have failed it."
Phone: (514) 282-8484 ext. 228                                   -Doug Camilli
mailto:lau...@uf...      Penguin Power!

Re: MSGedit fixes [was: Translation strings]

[Scott S. <st...@aj...>]

lau...@uf... said:

 > > I don't think
 > > there is any value, in fact negative value, in translating things
 > > like error messages.  This was discussed on the newsgroup before
 > > with the same resulting opinion.
 > > 
 > 
 > Hmmm... I don't remember this discussion. I don't think it's too late to
 > backtrack the error messages changes. I'm not sure it has no value, 
though.
 > I know that I've had system setups where part of the interface is 
English
 > and the rest is French. There is a "surprising" disconnect when you're
 > constantly working in French and all of a sudden an English message 
pops up.
 > It's even worse when part of the message is in English and the rest is 
in
 > French. It's not crucial or anything but it does give one a "weird" 
feeling.
 > I'm not sure how to describe it.

I believe the original motivation was that error messages are essentially 
part of the API of a command and changing them would cause programs to 
break.  Ideally, the errorCode would have the machine readable error state 
and the message would only be used to display to a user (and therefore 
should be localized).  Unfortunately most commands don't set the errorCode 
to anything useful so this isn't really an option right now.

Maybe we should consider improving the errorCode information with an eye 
toward localizing the messages later.

--Scott

Re: MSGedit fixes [was: Translation strings]

[<lau...@uf...>]

On 23 Jun, Jeffrey Hobbs wrote:
> This of course is restricted to just the end-user-visible strings,
> and not any error messages and the like, correct?

No. The error messages have been translated otherwise the test suite fails.

> I don't think
> there is any value, in fact negative value, in translating things
> like error messages.  This was discussed on the newsgroup before
> with the same resulting opinion.
> 

Hmmm... I don't remember this discussion. I don't think it's too late to
backtrack the error messages changes. I'm not sure it has no value, though.
I know that I've had system setups where part of the interface is English
and the rest is French. There is a "surprising" disconnect when you're
constantly working in French and all of a sudden an English message pops up.
It's even worse when part of the message is in English and the rest is in
French. It's not crucial or anything but it does give one a "weird" feeling.
I'm not sure how to describe it.

L

-- 
Laurent Duperval                   "Montreal winters are an intelligence test,
U|Force - Java Center                     and we who are here have failed it."
Phone: (514) 282-8484 ext. 228                                   -Doug Camilli
mailto:lau...@uf...      Penguin Power!

RE: MSGedit fixes [was: Translation strings]

[Jeffrey H. <jef...@aj...>]

This of course is restricted to just the end-user-visible strings,
and not any error messages and the like, correct?  I don't think
there is any value, in fact negative value, in translating things
like error messages.  This was discussed on the newsgroup before
with the same resulting opinion.

Jeffrey Hobbs                     Tcl Ambassador
ho...@Aj...          Ajuba Solutions (nee Scriptics)

> -----Original Message-----
> From: lau...@uf... [mailto:lau...@uf...]
	...
> will need to start looking at translating the C strings in Tcl and Tk.

Re: MSGedit fixes [was: Translation strings]

[Carsten Z. <ze...@tu...>]

I incoporated Jan's patches into MSGedit, an actual version is available
from 

http://www.tu-harburg.de/~skfcz/msgedit.tar.gz

The editor uses now the msgcat package provided with tcl, not the
included version from tcl8.1.

I've not look so far into the newer version of msgcat with substitution,
perhaps there will be some mistakes. And perhaps I should write some
doc  ...

By the way, anybody already found for german translation ?

Bye, Carsten

-- 
Dipl. Ing. Carsten Zerbst         |   See the results of the
                                  |   1. European Tcl User Meeting !
ze...@tu...              |  
http://www.tu-harburg.de/~skfcz   |   http://www.tu-harburg.de/skf/tcltk

Re: MSGedit fixes [was: Translation strings]

[<lau...@uf...>]

On 23 Jun, Carsten Zerbst wrote:
> By the way, anybody already found for german translation ?
> 

Andreas Kupries has provided me with the translations. He also found a few
bugs which I've corrected. So far I've checked that the fr, en and de
translations work properly with the test suites. I now have to do the es
ones. Once I've done that, I think that for the July 12 release of 8.4a2,
things should be complete as far as translations go.

Next week I'll try to fix the underlining problems and maybe the keybinding
problems. If I'm lucky, all will be completed for July 12. After that, we
will need to start looking at translating the C strings in Tcl and Tk.
That's a *much* larger job (which I may not take on). I know there are
facilities for this already. I know about gettext from GNU but that can't be
used in Tcl. A BSD-licensed technolgy will need to be used. If any of you
know of some clean solutions that exist already, which could be integrated
in the core, let me know so I can at least take a look.

L

-- 
Laurent Duperval                   "Montreal winters are an intelligence test,
U|Force - Java Center                     and we who are here have failed it."
Phone: (514) 282-8484 ext. 228                                   -Doug Camilli
mailto:lau...@uf...      Penguin Power!

Re: MSGedit fixes [was: Translation strings]

[<lau...@uf...>]

On 22 Jun, Jan Nijtmans wrote:
> lau...@uf... wrote:
>> - I don't do fonts. If you need something other than iso-latin-1, you need
>>   to figure out how to insert it into the translation scheme. Make it know
>>   immediately if you plan to work on this so that other users can
>>   synchronise their work with yours.
> 
> The solution to this problem is to use the "\uXXXX" format in the msgcat
> files for characters outside the ASCII range. This has the additional
> advantage that the msg files still contain only ASCII characters, so they
> work with whatever channel encoding is used when reading the msgfile.
> 
> Here is a patch for Carsten Zerbst's MSGedit with the changes I made.
> Are there already any Japanese, Korean or Chinese contributors who could
> possibly benefit from this?
> 

Thanks for the patch. No one has volunteered for any of the Far East (or
even Middle East) translations.

L

-- 
Laurent Duperval                   "Montreal winters are an intelligence test,
U|Force - Java Center                     and we who are here have failed it."
Phone: (514) 282-8484 ext. 228                                   -Doug Camilli
mailto:lau...@uf...      Penguin Power!

MSGedit fixes [was: Translation strings]

[Jan N. <j.n...@ch...>]

lau...@uf... wrote:
> - I don't do fonts. If you need something other than iso-latin-1, you need
>   to figure out how to insert it into the translation scheme. Make it know
>   immediately if you plan to work on this so that other users can
>   synchronise their work with yours.

The solution to this problem is to use the "\uXXXX" format in the msgcat
files for characters outside the ASCII range. This has the additional
advantage that the msg files still contain only ASCII characters, so they
work with whatever channel encoding is used when reading the msgfile.

Here is a patch for Carsten Zerbst's MSGedit with the changes I made.
Are there already any Japanese, Korean or Chinese contributors who could
possibly benefit from this?

Regards,
-- 
Jan Nijtmans, CMG Oost-Nederland B.V.
email: j.n...@ch... (private)
       jan...@cm...  (work)
url:   http://purl.oclc.org/net/nijtmans/

Re: Translation status

[Giorgos P. <pe...@ii...>]

In Ôñé, 20 Éïýí 2000, lau...@uf... wrote:
> The question I have for all of you: do you wish to have the translation
> strings when I've completed everything (which could take at least a week),
> or would you rather receive what I've done so far and receive more updates
> every few days?

Well, I prefer to have them whean all done, as I have also the dnd extension to
finish :-)

George

Re: Translation status

[Andreas K. <a.k...@we...>]

Seems my mail crossed with the information about the deadline.
I revoke my preference for a single gob and go with the notion
of doing it piecemal.

-- 
So long,
	Andreas Kupries <a.k...@we...>
			<http://www.purl.org/NET/akupries/>
-------------------------------------------------------------------------------

Re: Translation status

[Juan C. G. M. <jc...@gm...>]

lau...@uf... wrote:
> 
> Hi,
> 
> I'm still moving along with the translation. It's taking more time than I
> expected because there are some not immediately obvious situations that come
> up. I've done most of the translations for the dialogs, and now I'm going
> through the test suites (since they now fail if your native language isn't
> English). There will also need to be a test that changes locales and
> re-executes some of the tests scripts with a different locale. Something
> like
> 
> foreach l {en fr gr de nl(?)} {
>   ::msgcat::mclocale $l
>   ::msgcat::mcload $tk_library/msgs
>   wish choosedir.test
>   wish colrpick.test
>   .
>   .
>   .
> }
> 
> The question I have for all of you: do you wish to have the translation
> strings when I've completed everything (which could take at least a week),
> or would you rather receive what I've done so far and receive more updates
> every few days?
> 

Given the tight deadline, I'd prefer to start ASAP.

Juan Carlos---

Translation strings

[<lau...@uf...>]

Hi,

Here are the translation strings. The patches were made with CVS diff around
3:05 PM EDT. Applying them to a recent Tk tree should get you started. 

- Untar msgs.tar.gz in <tksrcdir>/library/

- to do the translations, make a copy of msgs/en.msg to msgs/es.msg (for
  Spanish)
  
- All you need to do is take each string and add the translation right
  beside it. I've put all the strings on one line (no \ for continuation)
  because it makes it easier to sort the files.
  
- The only tests that work are msgbox and choosedir. Running them should
  yield no errors.
  
- There are problems with buttons that have long names. The names are
  truncated on screen. I haven't yet figured out how to fix this. Eric, did
  you receive my note about min/max and tcllib?

- I don't do fonts. If you need something other than iso-latin-1, you need
  to figure out how to insert it into the translation scheme. Make it know
  immediately if you plan to work on this so that other users can
  synchronise their work with yours.

- To test, remember to set env(LANG) to the appropriate value before running
  the test.

L

-- 
Laurent Duperval                   "Montreal winters are an intelligence test,
U|Force - Java Center                     and we who are here have failed it."
Phone: (514) 282-8484 ext. 228                                   -Doug Camilli
mailto:lau...@uf...      Penguin Power!

Re: Translation strings

[Eric M. <er...@aj...>]

On Tue, 20 Jun 2000 lau...@uf... wrote:

> - There are problems with buttons that have long names. The names are
>   truncated on screen. I haven't yet figured out how to fix this. Eric, did
>   you receive my note about min/max and tcllib?

I did; after some consideration, I think that it's best if the core itself
is not dependant on tcllib.  The core should be completely independant.

- eric

Re: Translation status

[<lau...@uf...>]

On 20 Jun, Juan Carlos Gil Montoro wrote:
> Given the tight deadline, I'd prefer to start ASAP.
> 

I'll try to have something available tomorrow morning.

L

-- 
Laurent Duperval                   "Montreal winters are an intelligence test,
U|Force - Java Center                     and we who are here have failed it."
Phone: (514) 282-8484 ext. 228                                   -Doug Camilli
mailto:lau...@uf...      Penguin Power!

Re: Translation status

[Andreas K. <a.k...@we...>]

--------; charset=us-ascii

Seems my mail crossed with the information about the deadline.
I revoke my preference for a single gob and go with the notion
of doing it piecemal.

-- 
So long,
	Andreas Kupries <a.k...@we...>
			<http://www.purl.org/NET/akupries/>
-------------------------------------------------------------------------------

Re: Translation status

[Andreas K. <a.k...@we...>]

--------; charset=us-ascii

> Hi,
 
> I'm still moving along with the translation. It's taking more time
> than I expected because there are some not immediately obvious
> situations that come up. I've done most of the translations for the
> dialogs, and now I'm going through the test suites (since they now
> fail if your native language isn't English). There will also need to
> be a test that changes locales and re-executes some of the tests
> scripts with a different locale. Something like
 
> foreach l {en fr gr de nl(?)} {
>   ::msgcat::mclocale $l
>   ::msgcat::mcload $tk_library/msgs
>   wish choosedir.test
>   wish colrpick.test
>   .
>   .
>   .
> }

Or maybe something in the main wrapper calling the whole testsuite.

 
> The question I have for all of you: do you wish to have the
> translation strings when I've completed everything (which could take
> at least a week), or would you rather receive what I've done so far
> and receive more updates every few days?

I have no preference ... Hm, upon more cogitation I do have a slight
preference for the all at once approach. That makes it easier for me
to do it all at once too. Else I would collect the samples and then
go to work after I got them all.
 
> As for the core team, what's the freeze date on this?

-- 
So long,
	Andreas Kupries <a.k...@we...>
			<http://www.purl.org/NET/akupries/>
-------------------------------------------------------------------------------

Re: Translation status

[Eric M. <er...@aj...>]

This work is scheduled for 8.4a2, which is tentatively scheduled for
release July 12.  Thanks for your efforts, everybody, and keep it up!

   Eric Melski                            The Other Tcl Guy
   ericm at ajubasolutions.com            Ajuba Solutions

On Tue, 20 Jun 2000 lau...@uf... wrote:

> Hi,
> 
> I'm still moving along with the translation. It's taking more time than I
> expected because there are some not immediately obvious situations that come
> up. I've done most of the translations for the dialogs, and now I'm going
> through the test suites (since they now fail if your native language isn't
> English). There will also need to be a test that changes locales and
> re-executes some of the tests scripts with a different locale. Something
> like 
> 
> foreach l {en fr gr de nl(?)} {
>   ::msgcat::mclocale $l
>   ::msgcat::mcload $tk_library/msgs
>   wish choosedir.test
>   wish colrpick.test
>   .
>   .
>   .
> }
> 
> The question I have for all of you: do you wish to have the translation
> strings when I've completed everything (which could take at least a week),
> or would you rather receive what I've done so far and receive more updates
> every few days?
> 
> As for the core team, what's the freeze date on this?
>

Translation status

[<lau...@uf...>]

Hi,

I'm still moving along with the translation. It's taking more time than I
expected because there are some not immediately obvious situations that come
up. I've done most of the translations for the dialogs, and now I'm going
through the test suites (since they now fail if your native language isn't
English). There will also need to be a test that changes locales and
re-executes some of the tests scripts with a different locale. Something
like 

foreach l {en fr gr de nl(?)} {
  ::msgcat::mclocale $l
  ::msgcat::mcload $tk_library/msgs
  wish choosedir.test
  wish colrpick.test
  .
  .
  .
}

The question I have for all of you: do you wish to have the translation
strings when I've completed everything (which could take at least a week),
or would you rather receive what I've done so far and receive more updates
every few days?

As for the core team, what's the freeze date on this?

L

-- 
Laurent Duperval                   "Montreal winters are an intelligence test,
U|Force - Java Center                     and we who are here have failed it."
Phone: (514) 282-8484 ext. 228                                   -Doug Camilli
mailto:lau...@uf...      Penguin Power!

Tcl core, stacked channels, coordination note.

[Andreas K. <a.k...@we...>]

--------; charset=us-ascii

Things I spoke with Jeff about at 1st European ...


Next steps:

* Take the script-level 'unstack' command from Trf and the gIOT
  extension [1] and fold them into the core. This not only adds more
  stacked channel functionality into the core but facilitates testing
  of that functionality.

* Take the testsuites from TLS, Trf and gIOT and see what we can use to
  extend the test suite of the core.

* While doing this write a draft spec how to restructure the internals
  of stacked channels to address the remaining issues (hackish copying
  of channel structures, proper closing, transformations being able to
  catch and handle fileevents without upper levels knowing, etc.).

  Jeff and I had the same general idea of splitting the Channel
  structure into a master covering the highlevel things like event
  handling and a list of modules associating a stack of drivers with
  the master. We will have to work out the details though.

* Afterward, reimplement the stacked channels according to the
  finalized spec.

~~

* Listx: Stuff like porting the latest changes to the existing
  list-functionality (lsearch -sorted, ...) and integration into the
  core will be done by Jeff, or so I understood.

  We didn't talk about that part, but I hereby propose that the stubs
  table I added to listx be either made available separately to users
  of the core, or merged with the stubs table of the core.

  I strongly recommend to make the new functionality available at the
  C level.

~~

I volunteered to do the german translation of the strings used in the
tk dialogs, team leader is Laurent Duperval. This is something I
should be able to do in a single evening which I can squeeze in
anytime, so is no real burden.

Here is the location of a tool to make management of tcl msg
catalogs easier: http://www.tu-harburg.de/~skfcz/tcltk.html
Name: MSGEdit, Author Carsten Zerbst, presented at 1st European...

~~

[1] gIOT =	generic IO transformation. Enables the implementation
		of transformations at the scriptlevel. 

-- 
So long,
	Andreas Kupries <a.k...@we...>
			<http://www.purl.org/NET/akupries/>
-------------------------------------------------------------------------------