Re: Multilingual interface

2002-01-21 Thread Jeanne A. E. DeVoto

At 11:59 PM -0800 1/20/2002, Klaus wrote:
>i can just give some general hints on how to create multilingual projects.
>
>A good way is to store all the strings in text-files and reading them in
>e.g. after the user chose his favoutie language.

Easier I think to create a custom property set for each language, and store
strings in that. Then you can just switch custom property sets. Everything
is stored with the stack so no messy extra files to get lost, and it's only
one command.

--
Jeanne A. E. DeVoto ~ [EMAIL PROTECTED]
http://www.runrev.com/
Runtime Revolution Limited - Power to the Developer!


___
use-revolution mailing list
[EMAIL PROTECTED]
http://lists.runrev.com/mailman/listinfo/use-revolution



Re: Multilingual interface

2002-01-20 Thread Klaus

Dag Terry,

> Hi all,
> 
> Who has bright ideas on how to handle multilingual projects? Creating two
> (or more) separate stacks gives a lot of extra work; especially during
> development.
> 
> I was thinking about some kind of a language-preference that gives all the
> buttons another label and give some fields another content.
> 
> The main problem is that I don't understand how I can change the content of
> a menu. There is something about dynamically changing a menu in the Rev
> Encyclopedia: About menus and the menu bar. I have to put a mousedown
> handler in the group. But what should it contain? Are there any examples of
> it?

i can just give some general hints on how to create multilingual projects.

A good way is to store all the strings in text-files and reading them in
e.g. after the user chose his favoutie language.

Won't take too long, it's MetaCard, you know? ;-)

Takes some time for planning the whole thing, but lateron, you just have to
replace the textfiles or add some new languages.

If you do not have any idea on how to achieve this, drop a line :-)

> Also, would I need to extend the switch stucture like:
> 
> on menuPick pWhich
> switch pWhich
> case "Save"
> case "Bewaar" -- Dutch for 'Save'
>   saveStuff
>   break
> case "Quit"
> case "Stop" -- Dutch; well that doesn't have to be explained
>   quitStuff
>   break
> end switch
> end menuPick

Here the "menuhistory" could be a solution.

It returns the number of the menu picked !!!

So if you know that (what language ever) the menuitem "save" (of "Bewaar",
als jij daarvan houdt ;-) is the first item, you could use:

on menupick
  switch the menuhistory of me
  case 1
##your save stuff here
  break


I think you get the picture...

This way the menus could even be kisuaheli and they will work
nevertheless.
 
> Finally, can I discover what language the OS is, so I can set the standard
> language preference setting of my stack to it?

Jammer, no idea ;-)

> Terry

Greetings/groetjes


Klaus Major <[EMAIL PROTECTED]>
MetaScape GmbH

___
use-revolution mailing list
[EMAIL PROTECTED]
http://lists.runrev.com/mailman/listinfo/use-revolution



Re: Multilingual interface

2002-01-19 Thread Rob Cozens

>Who has bright ideas on how to handle multilingual projects?

Terry, et al:

You should also take a look at Revolution's Profile Manager Tutorial.

>From page 2:  "...you can use the Profile Manager to create multiple
language versions of your application,..."

I have not looked further into this yet; but if there is a method built
into Revolution via the Profile Manager, it's the obvious place to start.


Rob Cozens
CCW, Serendipity Software Company

"And I, which was two fooles, do so grow three;
Who are a little wise, the best fooles bee."

from "The Triple Foole" by John Donne (1572-1631)
___
use-revolution mailing list
[EMAIL PROTECTED]
http://lists.runrev.com/mailman/listinfo/use-revolution



Re: Multilingual interface

2002-01-19 Thread Scott Rossi

Recently, Terry Vogelaar wrote:

> Who has bright ideas on how to handle multilingual projects?

I don't know if they're bright ideas, but here's what we did.

We used a single stack to display content, with all text content, button
labels, alerts, etc stored in external text files.  All the files were
grouped in folders by language, and were provided by the client's
translators.  The benefit of this arrangement was the client could edit
content as often as they wanted, and all we had to do was swap the new text
files with the old.  We could also give development versions of the stack to
the client, and they could edit text and see the results of the editing in
place, without having to know anything about MC.

The stack had a language selection screen presented at startup.  Selecting a
language simply told the stack which set of external content to use when
loading the content into fields on various cards.

Alert/error dialog messages were all stored in a single text file for each
language, and were read into a global variable at startup for easy access.

This setup seemed to work ok, especially since text translators were located
all over the place and had different schedules for turning around
translations.  It is a lot of external files to manage, but if there's going
to be a lot of editing taking place, external files are much easier to deal
with.

FWIW,

Scott Rossi
Creative Director

Tactile Media, Multimedia & Design
Email: [EMAIL PROTECTED]
Web: www.tactilemedia.com

___
use-revolution mailing list
[EMAIL PROTECTED]
http://lists.runrev.com/mailman/listinfo/use-revolution



Re: Multilingual interface

2002-01-19 Thread Rob Cozens

>Who has bright ideas on how to handle multilingual projects?

Hi Terry,

Here is how I handle them:

* Dates, times, and numbers are are stored unformatted in a database and
are formated when displayed according to Mac OS Control Panel
specifications.

* Data labels and other on-screen literal text are replaced with icons.

* The application is 100% button driven, and the function of each active
button is displayed in a Help field when the cursor enters the button.

* There is a Translation screen where the user is presented each button
prompt & other help message in turn, and can translate them to another
language.

* There is a Configuration screen where the user selects a language and the
help prompts & other text for that language are loaded into the stack.

* The user manual is written in html so the user can translate it with any
html editor.

To see my design in action (in HyperCard), download the Mac demo at
http://www.oenolog.com/apple_demo.htm.  When OenoLog Version III was
released, I touted it to the press as the world's first "globalized"
business application: capable of end-user translation and world-wide
distribution (on Macs) in a single version.

I can't help you with the menu bar, since my application hides it.  I know
the Mac Human Interface Guideline police don't like that but:

A.  OenoLog softwqre was originally designed as a dedicated driver for
specialized instrument, not as a cooperative application to work seamlessly
with other Mac apps; and

B.  Frankly, I consider the menubar of today to be the DOS Prompt (">") of
yesteryear.  The menubar GUI was developed close to 30 years ago.  Ever
notice how most major software apps use a palette in addition to the
menubar today?  I believe "point & click" is superior to "pull down &
select" in most user interfaces, and I find a button-driven interface MUCH
easier to program than a menu-driven interface...especially one where the
menubar changes with different tool selections.


Rob Cozens
CCW, Serendipity Software Company

"And I, which was two fooles, do so grow three;
Who are a little wise, the best fooles bee."

from "The Triple Foole" by John Donne (1572-1631)
___
use-revolution mailing list
[EMAIL PROTECTED]
http://lists.runrev.com/mailman/listinfo/use-revolution



Multilingual interface

2002-01-19 Thread Terry Vogelaar

Hi all,

Who has bright ideas on how to handle multilingual projects? Creating two
(or more) separate stacks gives a lot of extra work; especially during
development.

I was thinking about some kind of a language-preference that gives all the
buttons another label and give some fields another content.

The main problem is that I don't understand how I can change the content of
a menu. There is something about dynamically changing a menu in the Rev
Encyclopedia: About menus and the menu bar. I have to put a mousedown
handler in the group. But what should it contain? Are there any examples of
it?

Also, would I need to extend the switch stucture like:

on menuPick pWhich
  switch pWhich
  case "Save"
  case "Bewaar" -- Dutch for 'Save'
saveStuff
break
  case "Quit"
  case "Stop" -- Dutch; well that doesn't have to be explained
quitStuff
break
  end switch
end menuPick

Finally, can I discover what language the OS is, so I can set the standard
language preference setting of my stack to it?

Terry


___
use-revolution mailing list
[EMAIL PROTECTED]
http://lists.runrev.com/mailman/listinfo/use-revolution