Closed Bug 315616 Opened 19 years ago Closed 17 years ago

[l10n] Talkback localizable.strings file improperly encoded

Categories

(Core Graveyard :: Talkback Client, defect, P4)

PowerPC
macOS
defect

Tracking

(Not tracked)

RESOLVED WONTFIX

People

(Reporter: lensovetp, Unassigned)

Details

Attachments

(1 file)

User-Agent:       Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.8b5) Gecko/20051020 Camino/1.0+
Build Identifier: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.8b5) Gecko/20051020 Camino/1.0+

The Localizable.strings file inside the English.lproj Talkback folders is encoded in Western (MacOS). However, it should be encoded in UTF-16 for localization purposes.

Reproducible: Always

Steps to Reproduce:
1. Navigate to the English.lproj directory inside the Talkback.app package
2. Open Localizable.strings
3. Look at the file encoding

Actual Results:  
File is encoded in Western (MacOS)

Expected Results:  
File should be encoded in UTF-16

Side note: do we have any access to this, or is it, along with the rest of Talkback, immodifiable? Also, the InfoPlist.strings file (in the same dir) is actually encoded correctly, in UTF-16.
Jay, how much access to the Talkback bits do MoFo/MoCo people have?  When mscott and bryner are doing things like fixing the branding and URLs (bug 244672, bug 243575), are they just hacking the existing binaries that sit somewhere and then get packaged in the apps, or are those names and URLs injected via a script/variable at app build/packaging time every build?

If mscott/bryner are just hacking the existing binaries, that's all we need to do to fix this bug (and maybe bug 187107, but I'm not sure), just a one-time replacement of a file.  (Paul, do you want to attach a converted Talkback localizable.strings here?)  

This particular bug is a real annoyance to caminol10n because every single build they go to localize, they have to dig into the app package for this Talkback localizable.strings and convert the file to change the encoding before starting the localization....
Status: UNCONFIRMED → NEW
Ever confirmed: true
Here's the modified localizable.strings file. Not sure if review is appropriate here, since I have no idea where this would go.
Attachment #202339 - Flags: review?
As far as I know, we were only able to localize Win32.  There is a talkback.l10n file that contains most of the strings used by the client.  It can be found in the extensions/talkback@mozilla.org/components directory... if simply changing those strings and modifying the encoding somewhere does what we want, we can look into that.

Not sure about Linux or Mac.  Cc'ing Shiva, Simon Montagu and Bryner in case they can help. 
On Mac we just have a Cocoa app whose nib and .strings files could be edited in-place to fix UI errors and assist with localization. Mac Talkback doesn't read strings from the .l10n or .ini files.
(In reply to comment #4)
> On Mac we just have a Cocoa app whose nib and .strings files could be edited
> in-place to fix UI errors and assist with localization.

How? where? please i'd like to fix this along with the Hide NewAPP bug.
(In reply to comment #5)
> (In reply to comment #4)
> > On Mac we just have a Cocoa app whose nib and .strings files could be edited
> > in-place to fix UI errors and assist with localization.
> 
> How? where? please i'd like to fix this along with the Hide NewAPP bug.

I don't think it's in the mozilla tree. It's added during build packaging.
Reassigning to Chase, since he would know more about where the Talkback files are packaged.  If this simply an issue of adding a new file to the Talkback.xpi, he might be able to help.
Assignee: jay → chase
it's a matter of touching the encoding of the .strings file inside the talkback app, inside the xpi. Is the talkback XPI static and sitting on the build machines or does it get created as part of the build?
In either case, since talkback doesn't seem to be in the mozilla tree, this will have to happen on the build end.
(In reply to comment #8)
> it's a matter of touching the encoding of the .strings file inside the talkback
> app, inside the xpi. Is the talkback XPI static and sitting on the build
> machines or does it get created as part of the build?
> In either case, since talkback doesn't seem to be in the mozilla tree, this
> will have to happen on the build end.
> 

so...do we have someone (on the build end) that can do this?
Mass reassign of open bugs for chase@mozilla.org to build@mozilla-org.bugs.
Assignee: chase → build
Attachment #202339 - Flags: review? → review?(joshmoz)
Priority: -- → P4
Comment on attachment 202339 [details] [diff] [review]
UTF-16 localizable.strings

r+ for moving this file to UTF-16. Whoever does it should not use the attachment here, but just change it to UTF-16 themselves in case it changed... Easy to do with Xcode.

preed - can you do this?
Attachment #202339 - Flags: review?(joshmoz) → review+
Not shipping talkback on trunk, hence wontfix.
Status: NEW → RESOLVED
Closed: 17 years ago
Resolution: --- → WONTFIX
Product: Core → Core Graveyard
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: