Bug 1549 - Strings in installing progress bar aren't translated
: Strings in installing progress bar aren't translated
Status: ACCEPTED
Product: installer
other
: unspecified
: i86pc/amd64 OpenSolaris
: P3 normal (vote)
: 2010.1H
Assigned To: installer watcher
:
:
: reviewed-2009.06 software-l10n
:
:
: 7740
  Show dependency treegraph
 
Reported: 2008-04-24 22:06 UTC by simon zheng
Modified: 2009-07-30 04:09 UTC (History)
6 users (show)

See Also:


Attachments


Note

You need to log in before you can comment on or make changes to this bug.


Description simon zheng 2008-04-24 22:06:29 UTC
When installing in Chinese-Simplified, most of strings in progress bar are
still in English rather than Chinese, such as "Transfering LiveCD content".
Comment 1 Dave Miner 2008-04-25 07:08:36 UTC
Didn't have time to get l10n infrastructure down to the infrastructure where
these strings are generated.
Comment 2 Dave Miner 2008-04-28 10:44:45 UTC
*** Bug 1677 has been marked as a duplicate of this bug. ***
Comment 3 William Schumann 2008-09-03 12:20:52 UTC
These strings for the progress bar originate in Python source code in the
Transfer Module.  xgettext(1) is used to find strings for localization in C
code, but Solaris xgettext does not accommodate Python.

However, GNU xgettext has been ported as gxgettext, which can locate the
strings in Python source code and generate PO files for localization. (Thanks,
Kenjiro Tsuji)

The Transfer Module Makefile can be modified to produce the PO files for
localization of messages using gxgettext in a manner similar to xgettext for
the C language.

transfer_mod.py should be modified to use the gettext module to identify the
strings for localization and perform the translation.

xgettext from GNU gettext package is available as /usr/bin/gxgettext
or /usr/gnu/bin/xgettext on Solaris. 

One approach to coding this is to duplicate the procedure used elsewhere in the
install code.
sample Makefile code:
MSG_DOMAIN    = SUNW_INSTALL_<your module>
PYMODS        = list of your .py modules
...
for use with 'make install' target:
$(MSG_DOMAIN).po:    $(PYMODS)
    @echo "Making messages file ${MSG_DOMAIN}.po"
    @/usr/gnu/bin/xgettext -s -o $@ $(PYMODS)
    @$(CHMOD) 0755 $@
    @$(RM) $(ROOTUSRLIBMSGS)/$@
    $(CP) $@ $(ROOTUSRLIBMSGS)
-produces a single sorted POT message file from a list of source modules.
-copies the .po file to proto area usr/lib/locale/C/LC_MESSAGES

This install consolidation method differs from the method used in ON in that
for ON, message files are concatenated before being copied to the proto area.
Comment 4 Moriah Waterland 2009-03-24 12:01:08 UTC
The following messages on the Installation Progress Panel also need to be
localized:

- Preparing for OpenSolaris installation...
- Building file lists for cpio
- Building cpio file lists
-complete transfer process
Comment 5 Moriah Waterland 2009-03-24 12:02:21 UTC
Also the following messages are need to be localized when a network cable is
unplugged or plugged in:
- 'Took interface.... down'
- 'Brought interface ... up, got address ...'
Comment 6 Moriah Waterland 2009-03-24 12:06:51 UTC
Closing 3083 as a dup of this bug.    I imported the comments from 3083 below:


Comment #1 From  PrasadKDM   2008-08-26 23:08:54   (-) [reply] -------

Created an attachment (id=448) [details] [details]
unlocalized message during installation

------- Comment #2 From Takeshi Asano 2008-08-26 23:47:21 (-) [reply] -------

Regarding the Installation Progress Panel messages, they
are not i18ned yet (i.e. gettext'ed and extracted to .pot
file) so not translated yet.

I understand that at 2008.05 there was a plan to refine
the set of messages then i18n of the messages was postponed
until the refinement is done.

I'm transferring this bug report to category for slim installer
for checking status of the message set refinement and i18n.

Regarding the Unplug/Plug messages, they look to be nwam messages
which will need separate bug report for them.

------- Comment #3 From Sanjay Nadkarni 2008-10-22 19:12:28 (-) [reply] -------

We should fix for 2008.11.

------- Comment #4 From Takeshi Asano 2008-10-22 19:26:04 (-) [reply] -------

Sanjay, this is i18n issue rather than l10n issue.
(i.e. "not ready to translate" rather than "not translated")

If you think this bug should be solved based on current set
of messages, please clarify these information:

- Which module generates the messages?
- Message domain name?
- Message search path? (/usr/lib/locale, /usr/share/locale, other?)
- List of messages?

------- Comment #5 From Takeshi Asano 2008-10-22 23:22:20 (-) [reply] -------

I briefly looked at sources in the slim gate.

- Preparing for OpenSolaris installation...
    -> This looks to be a message generated by gui-install
       itself. Just missing _().

   219                  case INSTALLATION_TYPE_INITIAL_INSTALL:
   220                         
MainWindow.InstallationWindow.current_install_message =
   221                                          g_strdup("Preparing for
OpenSolaris 2008.11 installation");
   222                          break;

-Building file lists for cpio
-Building cpio file lists
-Transfering Live CD Contents (Actually "Transferring Contents")
-complete transfer process (Actually "Complete transfer process")
    -> These look to be messages generated by libtransfer then
       passed to gui-install.
       Needed to i18n transfer_mod.py, or alternatively apply _()
       in gui-install side in installation-screen.c, could be at here:

   659                                  case OM_SOFTWARE_UPDATE :
   660                                         
MainWindow.InstallationWindow.current_install_message =
   661                                                 
g_strdup(cb_data->message);

------- Comment #6 From Frank Ludolph 2008-10-23 09:10:11 (-) [reply] -------

As Sanjay pointed out, two of the messages contain jargon that is not
meaningful to many users.

-Building file lists for cpio
-Building cpio file lists

In fact, while I know what cpio is, I don't understand how these are different.

I suggest replacing both with a single message

- Preparing to transfer files
Comment 7 Moriah Waterland 2009-03-24 12:07:08 UTC
*** Bug 3083 has been marked as a duplicate of this bug. ***