709877 - Determine how l10n will work between Native Fennec & Native Sync

Status: RESOLVED FIXED

(Firefox for Android Graveyard :: Android Sync, defect)

Description

[Allison Naaktgeboren :ally]

the original plan for l10n may have to be scrapped since the original build/packaging plan has not worked out.

May not make v0 drop

Comment 1

[Axel Hecht [:Pike]]

With a bit of discipline, this isn't too hard to get working:

Make the sync strings.xml be structured in the same way as in native, that is, split it into an xml with &refs; and externalized a DTD.

Copy that DTD next to android_strings.dtd, and make the strings.xml.in include both android_strings.dtd and, say, sync_strings.dtd.

Comment 2

[Richard Newman [:rnewman]]

(In reply to Axel Hecht [:Pike] from comment #1)

> Copy that DTD next to android_strings.dtd, and make the strings.xml.in
> include both android_strings.dtd and, say, sync_strings.dtd.

Yup, clear on how to do it, just need to find the time to do it with all the other blocker bugs!

Bug 709391 shows the current first draft. If someone else finds the time to layer a patch on top of that and submit a pull request to the android-sync GitHub repo, I will gladly try it out and merge it in.

Comment 3

[chris hofmann]

At the meeting we had a few weeks ago we talked about two possible options.

1) have the sync build process push strings in and out of verbatim ( https://localize.mozilla.org/ ) for localization teams to translate.  This would work best with some kind of .po to android XML file converter.

2) have the sync build process push strings in and out of hg ( https://hg.mozilla.org/mozilla-central/file/296ce6c97770/mobile/android ) and localization teams would work in much the same process as they do now for the rest of native android.  this works best with some kind of .dtd to android XML file converter, and or the process I think Axel layed out in comment 1.

Have we narrowed down to which out of these to approaches we are going to go with?

Comment 4

[Richard Newman [:rnewman]]

(In reply to chris hofmann from comment #3)

> Have we narrowed down to which out of these to approaches we are going to go
> with?

The situation has changed somewhat, given the amount of effort that getting built with Fennec took.

The answer is currently "neither", because we dump a strings.xml fragment into Fennec's strings.xml.in. This bypasses localization completely. (Sorry, but at 3:30am I was feeling quite single-minded.)

Eventually it will be easiest to do (2), and we'll just dump our strings into Fennec's DTDs instead of strings.xml.in, and rely on the appropriate magic happening downstream. If/when we package Sync standalone, I'll write a tool to pull localized files out of Fennec and back into our own system.

Comment 5

[Axel Hecht [:Pike]]

(In reply to Richard Newman [:rnewman] from comment #4)
> (In reply to chris hofmann from comment #3)
> 
> > Have we narrowed down to which out of these to approaches we are going to go
> > with?
> 
> The situation has changed somewhat, given the amount of effort that getting
> built with Fennec took.
> 
> The answer is currently "neither", because we dump a strings.xml fragment
> into Fennec's strings.xml.in. This bypasses localization completely. (Sorry,
> but at 3:30am I was feeling quite single-minded.)

If you're already doing one fragment that you can't use like that in standalone, then there's no reason to not use two, one in l10n and one not.

l10n is not OK to drop.

> Eventually it will be easiest to do (2), and we'll just dump our strings
> into Fennec's DTDs instead of strings.xml.in, and rely on the appropriate
> magic happening downstream. If/when we package Sync standalone, I'll write a
> tool to pull localized files out of Fennec and back into our own system.

Don't do that, that's the exact opposite of what we already discussed. It's just going to make your life and the life of localizers more awkward.

Comment 6

[chris hofmann]

> The answer is currently "neither", because we dump a strings.xml fragment
> into Fennec's strings.xml.in. This bypasses localization completely. (Sorry,
> but at 3:30am I was feeling quite single-minded.)

Let's stick to the plan, or provide a rational behind a better plan if there is one.

Comment 7

[Richard Newman [:rnewman]]

(In reply to Axel Hecht [:Pike] from comment #5)

> If you're already doing one fragment that you can't use like that in
> standalone, then there's no reason to not use two, one in l10n and one not.

I would be very happy to have someone else do this work, because I don't even have the time to investigate your suggestion. As soon as I get a Makefile that yields an app on my emulator, I'm on to the next task.

(My Makefile apparently bitrotted in the past five days. This is enormously frustrating.)


> l10n is not OK to drop.

We have no intention of dropping it; it'll be addressed in early January. Ally, Erin, and Sheila have more details.

If this were advance-scheduled work, we'd certainly be trying to be thorough and plan ahead... but we'd also have nine months in which to build this and get it all neat and tidy. As it is, we've had six weeks to try to build an entire Sync client from scratch, talking to databases that haven't been fully implemented, on an unfamiliar platform.

Localization is important, yes, but right now I'm concerned with somewhat lower-level issues like "builds and installs" and "uploads records". Those have to come first, because without them we don't even have a demo, let alone a product.

> Don't do that, that's the exact opposite of what we already discussed. It's
> just going to make your life and the life of localizers more awkward.

Alas, my life is already awkward! I did it this way because the alternative is "it doesn't build". That's not a choice. When we get a moment to breathe we'll do whatever works best for you guys.

Seriously, I'm not trying to make your life hard here; I'm trying to deliver the absolute bare minimum thing that can be considered "and here's Fennec with Firefox Sync support". There are *lots* of things that need to be improved before I'll consider this release-quality, and fitting comfortably into a localization toolchain is one of those things.


(In reply to chris hofmann from comment #6)

> Let's stick to the plan, or provide a rational behind a better plan if there
> is one.

The plan is not 'better', it's 'produces an installer rather than failing in Make'. That's not ideal, but it's a pretty compelling rationale to me.

Comment 8

[Axel Hecht [:Pike]]

I folded and submitted a pull request, https://github.com/mozilla-services/android-sync/pull/4.

That is not an l10n review, but merely me doing 10 minutes of typing for you.

Comment 9

[Richard Newman [:rnewman]]

(In reply to Axel Hecht [:Pike] from comment #8)

Thanks.

The sharp end of the stick is the Fennec build side.

Comment 10

[Richard Newman [:rnewman]]

I think this is done (see Bug 709391). Axel, do you agree?

Comment 11

[Axel Hecht [:Pike]]

Yes, this should work allright. It's a bit of a call as we don't have folks localizing mobile yet and the feature is off, but if anything unexpected happens, I'll file a new bug.

Marking this one FIXED, thanks.