Yes, you're right. It may be a bug in case the string order is important in the application and will address the bug in the normal build tests. But if the application just check either equal or not in the two strings, probably I think strcmp() is not a problem. However those issues are out of I18N pre-evaluation because g_utf8_collate() is available and GNOME applications link to libglib-2.0.so.
If none glib application has the problems in the string conversions for end user UI and does not have the proper APIs, the problem will be shown as "NG" in I18N pre-evaluation. Does this resolve your concern? Thanks, fujiwara simon.zheng at sun.com wrote: > Hi Takao, > > One question that has no bearing with mousetweaks. Does UTF8 strings > issue belong to I18N? For example, a string from gtk entry which is in > UTF-8 encoding, but appliaction often uses strcmp() to operate this > string. Can we regard this kind of bug as I18N issue? > > Thanks, > -Simon > > Takao Fujiwara - Tokyo S/W Center wrote: > >> - mousetweaks(pointer-capture-applet, dwell-click-applet): GO works >> with gnome-mouse-properties >> >> >> Message I18N >> ============ >> - OK: textdomain(3C) is configured. >> >> Printing >> ======== >> - N/A >> >> String >> ====== >> - N/A >> >> File Operation >> ============== >> - N/A >> >> Character set >> ============= >> - OK: glib is linked. >> >> Fonts >> ===== >> - N/A >> >> Locales >> ======= >> - OK: locale can be imported. >> >> Keymaps >> ======= >> - N/A >> >> Shortcuts >> ========= >> - N/A >> >> InputMethod >> =========== >> - N/A >> >> Image, Sound, movie >> =================== >> - N/A >> >> Accessibility >> ============= >> - N/A >> >> CDE compatibility >> ================= >> - N/A >> >> _______________________________________________ >> desktop-discuss mailing list >> desktop-discuss at opensolaris.org >> > > >
