Great,
I will contact you during the .7 release to aid us in producing a
Spanish translation.
--Brian
Brian Kirsch - Email Framework Engineer
Open Source Applications Foundation
543 Howard St. 5th Floor
San Francisco, CA 94105
(415) 946-3056
http://www.osafoundation.org
Daniel Vareika wrote:
Dear Brian,
First and foremost, sorry I could not answer before, not that I did
not want to, but because I wanted to take the time to read thoroughly
first your mail and then the web page.
All I can say is that one never thinks of the complexity that it´s
involved with translating a program to another language least a
program like Chandler.
Please feel free if I can be of any help
Obviously I can do so in Spanish.
One thing that through time I have noticed between English Software
and it´s Spanish Counterpart, is that people rarely know the right
dialects of Spanish, or haven´t done a neat job trying to do a
"universal" Spanish translation if I might say so.
On the other hand, words in Spanish are usually much more longer,
making a menu sometimes unreadable for it´s complexity.
Similar things happens with strings of text that doesn´t fit in a
window (as does the English part) or even buttons!
As I have said, I am here to help being my only limit, time availability.
Yours,
Daniel
See below a not so horrible example of the Layer Menu of Photoshop
(you should have seen the first incarnations in Spanish of this program!)
It´s almost like reading a book going through menus!
example
Brian Kirsch wrote:
Hi Daniel,
The i18n process I am referring to is moving Chandler from its roots
as an English only ASCII Application to a full fledge
internationalized / localizable Platform.
.6 is the first release where we have implemented components of
internationalization (Unicode support, I/O conversion, Schema
alteration, etc). Much has been done in the release and much is still
to be done to reach our 1.0 goals.
To better give you an idea of what are I18n goals are here is some
information taken from our Internationalization Project Wiki home
page
(http://wiki.osafoundation.org/bin/view/Projects/InternationalizationProject):
====================
The Internationalization (I18N) of the Chandler PIM is a long process
that will require a variety of changes to the current architecture.
This processed will be staged through out the release cycle and will
continue beyond Chandler 1.0.
The 1.0 release will feature the infrastructure for
Internationalization. It will ship with an example localization of
the application in Spanish. In addition, an example tutorial on 'How
to localize your parcel' will also ship with the developer version
and will contain a sample translation in Spanish.
The infrastructure provided by the Chandler for 1.0 will include:
The ability to localize the graphical user interface including menu
label strings, dialog and windows title strings, tool tip strings,
status text.
The ability to localize media include images, icons, sound, and HTML.
The ability to localize and customize style information such as font
type, font size, background and foreground colors.
The ability to localize example content.
Software tools to ease the translation process.
Chandler localizations are performed on a domain. A domain can apply
to one parcel or many parcels. For example, all parcels that ship as
part of the core Chandler Application Framework are in the "osaf"
domain. A third party developer could define a single domain for his
or her parcels. The name can be any unique ASCII string, for example
"com.codebear".
Some aspects of Internationalization are beyond the scope of 1.0
including:
Alternate layout presentation for a given locale.
Spell check, auto complete, and search behavior appropriate for a
localized market.
Locale specific word and sentence boundary recognition.
Community participation will play an import role in our I18N
strategy. The OSAF team has neither the developer resources nor the
linguistic expertise required to produce translations for the
multitude of languages spoken across the globe. This is where we turn
to our supporters to help provide translations. The team will be very
responsive to the community and will work closely with localization
developers. This includes making adjustments to the i18n road map
based on the participation of the community. For example, if a
volunteer was excited about alternate locale GUI presentation and
wanted to contribute code to help make this goal a reality in
Chandler 1.0, a member of the staff would take time to work with the
person providing technical assistance.
Brian Kirsch - Email Framework Engineer
Open Source Applications Foundation
543 Howard St. 5th Floor
San Francisco, CA 94105
(415) 946-3056
http://www.osafoundation.org
Daniel Vareika wrote:
Brian:
What is "the i18n process"?
Sorry for my ignorance!
Daniel
Brian Kirsch wrote:
Hi Daniel,
I hope you did not find the tone of my email negative. I was only
trying to give you a road map of where we are in the i18n process.
I certainly appreciate feedback from real users who understand the
importance of i18n and how a lack of localizability is a key factor
for non-english users abandoning an otherwise well thought out app.
The 24 / am pm suggestion is a very good one certainly will make it
in to Chandler at some point.
-Brian
Brian Kirsch - Email Framework Engineer
Open Source Applications Foundation
543 Howard St. 5th Floor
San Francisco, CA 94105
(415) 946-3056
http://www.osafoundation.org
Daniel Vareika wrote:
Brian,
I never meant to say which feature should go where.
I am only trying from a user stand point to see how it should be,
to be able to question myself first and also others with the
highest regards.
What I believe is that if you (anyone) knows good enough your
goals, we can minimize the impact of having to re code things that
haven´t been thought of at start even though as you described, it
could have different incarnation between versions.
Most of all I appreciate your work and the time you are spending
reading others e mails.
Yours,
Daniel
Brian Kirsch wrote:
Hi Daniel,
Well that certainly would be a nice feature. Since we leverage
the ICU for all our date calculation the easiest would be to see
if the API has this functionality my guess is not. Again my first
priority is that we correctly determine the locale and timezone
info from the OS. The next step would be to get the custom date,
time, currency, and number info which one can specify as an OS
preference. And then finally to have overriding configurations
such as use am / pm even though the OS say to use 24 hour.
So I will certainly keep this in mind as a goal for 1.0 but it
will not make it in to the .7 release for sure.
Thanks again for all your feedback,
Brian
Brian Kirsch - Email Framework Engineer
Open Source Applications Foundation
543 Howard St. 5th Floor
San Francisco, CA 94105
(415) 946-3056
http://www.osafoundation.org
Daniel Vareika wrote:
Brian:
I checked my system and in that it seems to be that UY goes by
the notation am/pm instead of 24hr.
But in Uruguay we use both!
I believe that in the Calendar view the easiest to see is the 24
hr notation but regardless of my preferences and the preferences
of someone that might not be even be or live in Uruguay, this
should be strictly user selectable or changeable in a preference
control panel of Chandler.
At first it might choose to use the Country notation but the
user should have the ability to change this in particular.
Yours,
Daniel
PS It doesn´t seem to be a bug.
I didn´t change regions though to see if it changed within
Chandler.
Is your OS setup to display 24hr or am/pm?
We want to leverage what ever configuration is specified in the
OS. If there is a mismatch (your OS is 24hr but Chandler is
am/pm) then that is a bug.
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
Open Source Applications Foundation "Design" mailing list
http://lists.osafoundation.org/mailman/listinfo/design
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
Open Source Applications Foundation "Design" mailing list
http://lists.osafoundation.org/mailman/listinfo/design
