On Dec 19, 2006, at 6:19 PM, Andy Dent wrote:
On 20/12/2006, at 2:46 AM, Tim Jones wrote:
Have you looked at the options that Package Maker provides for
language selections?
G'day Tim
Unfortunately this has to be a cross-platform solution.
Hi Andy,
That explains everything! I also wish there were a cross-platform
tool for distribution that offered the power and simplicity of
Apple's Package Maker. There are a lot of tools out there (and more
coming almost daily), but none of them work as seamlessly and easily
as PackageMaker on the Mac.
I presented the client with a set of three options and for now we
have gone back to the RB5 style of individual builds (option 1)
The alternatives boil down to:
1) we do language-specific builds, one executable per build, as in
prior builds. The installer either
a) only includes one build, so is language-specific
b) has several builds on a CD so can choose which at install-time
c) is a live downloader, choosing which language at install-time
I believe that this is what most of us are currently doing where we
depend on RB's built-in language support.
2) using Dynamic Constants, so a single build is delivered, with
the ancillary folder for Windows. Depending *solely* on the user's
language setting on their computer, the correct language is invoked
at the time the program runs. There is no install-time control.
Note that Dynamic Constants have been very buggy throughout the
RB2006 releases and still have some minor issues.
This has been shown recently to not be working as it should (as you
state), so it gets a hmmmm.
3) Developing a facility of our own for live constants throughout
the program. This would provide ultimate flexibility including:
i) runtime change of language, at any time whilst running the program
ii) ability to mix languages, eg: native language for tooltips but
English titles
iii) install-time restrictions on languages, as you requested
iv) customisable tooltips and other extensions, so you could have
"expert mode" as a "language" or "Compact German" titles for laptop
use
v) shipping additional language sets later without having to revise
the program
vi) adjusting control font size if the text is too big
vii) finer control over the presence of tooltips - they could be
suppressed for example on some controls, possibly at the user's
discretion
viii) putting you in sole charge of editing the text for the user
interface - you would have an external editor you used to change
the text which would also allow you to pass both the program and
that editor off to a translator, if requested, so they could tweak
translations to suit
A lot of true international apps appear to be using this with the
language being chosen as part of the app's preferences or based on
the users' language settings. I know that one user a few years back
gave up on the constants in RB and created "strings" modules that
created his strings as properties (variables) and then he can modify
the settings by running a method that updates the values assigned to
the properties. That could actually work better for you as it would
also allow you to track the platform so you can more readily modify
the control size and placement for Linux and Windows since autoresize
is not a control option for RB as it was in VB.
I'm actually rethinking our apps to move to this mechanism since
dynamic constants (isn't that an oxymoron?) don't work properly right
not in certain circumstances.
Tim
--
Tim Jones
[EMAIL PROTECTED]
_______________________________________________
Unsubscribe or switch delivery mode:
<http://www.realsoftware.com/support/listmanager/>
Search the archives of this list here:
<http://support.realsoftware.com/listarchives/lists.html>
