Growl localization procedure proposal
Peter Hosey
I've drafted:
----
# Growl localization process
## During development
We only touch the English xib.
## Start of the localization period
- We declare a freeze on all changes to xib and strings files.
(Ideally, just a string freeze.)
- We incrementally update each non-English xib to match the English
xib. [Tool #1]
- We lock the non-localizable properties in each non-English xib.
(Currently can only be done in the IB GUI: x-radar://problem/7564393)
- We bundle up each language's xib and strings files and send that
archive to the appropriate localizer. This should be a tarball so that
programmer-localizers can untar it into a Growl source code directory.
## When a finished localization arrives
- We untar/unzip their localized xib and string files.
- For strings files, we simply replace them, and use hg diff to make
sure nothing got deleted that shouldn't have been.
- For xib files:
- We incrementally apply their changes between our old English xib,
our old localized xib, and their updated localized xib to produce our
new localized nib. (This is a single ibtool command for each of our
xibs: one for fr/foo.xib, one for fr/bar.xib, one for es/foo.xib,
etc.) [Tool #2]
## When all localizations have arrived
- We declare the end of the string freeze/localization period.
- We ship!
----
The tools will be for us, the developers, and will automatically use
hg to retrieve the two different (old and new) versions of the two
different languages of each file and feed those four files to ibtool.
Without the tools, we'd have to extract the four versions of the file
manually, which would suck.
Localizers will need nothing more than a text editor and Interface
Builder. I have no idea whether iLocalize will help you here; if it
would, feel free to use it, so long as you can send us strings and xib
files.
Localizers: When working in IB, please use the Strings list window
(which you can access from the Tools menu or by pressing ctrl-S). This
gives you a list of every string in the file. It'll help you miss
nothing, while providing easy double-click access if you want to see a
user-interface element in context.
jpk
> Localizers will need nothing more than a text editor and Interface
> Builder. I have no idea whether iLocalize will help you here; if it
> would, feel free to use it, so long as you can send us strings and xib
> files.
iLocalizer is a very good text editor and can do the link with
Interface Builder.
More !!!
iLocalizer can manage several glossaries to help the localizer and
avoid hem/her to waste time to retrieve previous string translations.
iLocalize can remember the previous localizations of an application
and so the localizer has to work only on the modified parts of the
application.
With iLocalize the localization update of a new version is not a pain.
So the localization process can accompany the development one. It is
not needed to wait the end of the development to begin the
localization and, sometimes, to find specific problems (as example the
need to have more strings to translate gender and/or plural variable
strings).
Peter Hosey
> iLocalizer can manage several glossaries to help the localizer and
> avoid hem/her to waste time to retrieve previous string
> translations. iLocalize can remember the previous localizations of
> an application and so the localizer has to work only on the modified
> parts of the application.
The process I've proposed achieves the same goal; the locked-down
ready-to-localize xib you'll receive should contain all previous work
plus any new strings/controls.
(I say “should” because I haven't tested our side of this procedure
yet, in turn because I haven't finished writing the tools for it yet.)
Chris Forsythe
I think what jpk is pointing out is they have a fancy interface with
tables to highlight the changes, rather than having to go hunt them
down within the xib/nib.
Or is there more to it jpk?
jpk
> I think what jpk is pointing out is they have a fancy interface with
> tables to highlight the changes, rather than having to go hunt them
> down within the xib/nib.
Indeed.
iLocalize can compare a N original version with the N-1. Then it
points the changes between the two, modified strings and/or nibs. So
the localizer has to adapt the localized version for the changes only.
The rest of the localization can/must remain unchanged.
Little by little during the develpment process the localizer has less
and less work to do as the UI becomes more stable. And the testable
beta version can (almost) always be at the same level as the original
English one.
Chris Forsythe
So here's the problem. If we use ilocalize's process, then it's a lot
of work for us. And we have 2-3 people on the Growl team now. Nobody
has the time to handle processing these into Growl manually, which
results in us not wanting to handle localizations at all really.
Can you find out if we can script ilocalize? What I really want is to
put them into a directory, and then have a folder action do the rest
of the work. Then I just check it in, and not worry about it.
If it can't be scripted, what I'd prefer to use is a strings file,
where *anyone* can edit it, even on other platforms like linux and
windows. I know, I know, you don't get to resize nibs, but what I was
hoping is we had some stuff that would automatically resize nibs anyhow.
The current process sucks for us because it's time consuming, and we
don't have time anymore. If I had 15 devs like I used to, I would be
singing a different tune. But that's no longer our reality.
Thoughts? Suggestions?
Chris
Evan Schoenberg, M.D.
Adium's localization import process uses a script (adium/Utilities/Localization Utility Scripts/update_adium_from_bundle) to copy all the files from a bundle to the correct places in the source tree.
Using a single strings file is unfortunately not an option. Adium uses control autoresizing code to minimize the number of nibs that needs localization, but it can't work in all cases.
-Evan
Christopher Forsythe
Alexander Henket
--
You received this message because you are subscribed to the Google Groups "Growl Localizations" group.
To post to this group, send email to growl-loc...@googlegroups.com.
To unsubscribe from this group, send email to growl-localizat...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/growl-localizations?hl=en.
Evan Schoenberg, M.D.
On Mar 9, 2010, at 1:17 AM, Alexander Henket wrote:
> I would suggest taking scripting iLocalize up with the iLocalize group, or the developer directly.
I'm not sure what scripting iLocalize is intended to accomplish.
>
> I would also suggest to:
>
> - Drop the idea of getting the localizations into your Xcode project. Just have English there and finish the application including localizations in iLocalize. All it takes is the discipline to freeze a certain build in Xcode and deem it ready to be released through iLocalize.
So you suggest developers use iLocalize to import each language from a submitted bundle into a release bundle? This sounds cumbersome and not at all automated, but perhaps I misunderstand the process you're proposing. Have you used this for development, or are you speaking from a localizer's standpoint?
> - Create a one size fits all UI, so you do not have to distribute any nibs/xibs on a localizable location, thus saving space and effort on both ends. You just needs to be committed to creating that one size fits all version
That's definitely not a plan we're going to embrace; restricting your UI design to one-size-fits-all is not attractive.
> - This means that all localizers have to do is translate Localizable.strings files, test and document what parts in the UI do not fit if any
Or localizers could translate strings and nibs (xibs). Tools like iLocalize make this an easy process.
> I would hate to see localizations dropped. As you have seen in the group, the number of people wanting to add their language is growing and growing. Please don't consider localization a burden, but as a good thing for your project. I also do localizations work for companies of just one man, so you have threefold the capacity to make this work compared to them.
Localization is most certainly a burden and significant headache no matter how streamlined your process is, though it is also a plus for users. There is, however, no talk here of dropping localizations; we're simply trying to minimize the pain of the process. Note that Growl's situation is more complex than most applications due to the huge number of bundles and supporting extras involved in a given localization.
-Evan