[HELP] Macedonian localization for android 4.0.3

[Macedonicus]

Hey guys, I would like to volunteer by translating the latest version of Android in Macedonian.
I have no skills or knowledge in coding or programming so my contribution would be only in translating the sentences from English to Macedonian.
Could anyone help me with that and explain the process of localization?
Thank you.

[Jean-Baptiste Queru]

Sorry I didn't get to reply earlier.

Unfortunately, we're not currently set up to be able to accept
community translations. The actual translation work is done on
Google's internal servers, using a service that is common to all
Google products (and not just to Android). The xml files that are in
the Android source tree at the output of that service, they're never
modified manually.

Since that internal service isn't accessible outside of Google,
there's no practical way to organize community translations.

Occasionally, we can tweak an individual translation, by manually
copying a single string from an AOSP contribution into the translation
service, but we can't possibly scale up to the entire set of strings.

I'm afraid that you're not going to be able to help us on this, sorry.

Thanks for your interest.
JBQ

--
Jean-Baptiste M. "JBQ" Queru
Technical Lead, Android Open Source Project, Google.

Questions sent directly to me that have no reason for being private
will likely get ignored or forwarded to a public forum with no further
warning.

[Shachar Shemesh]

On 06/09/2012 04:20 AM, Jean-Baptiste Queru wrote:

Sorry I didn't get to reply earlier.

Unfortunately, we're not currently set up to be able to accept
community translations. The actual translation work is done on
Google's internal servers, using a service that is common to all
Google products (and not just to Android). The xml files that are in
the Android source tree at the output of that service, they're never
modified manually.

Since that internal service isn't accessible outside of Google,
there's no practical way to organize community translations.

Occasionally, we can tweak an individual translation, by manually
copying a single string from an AOSP contribution into the translation
service, but we can't possibly scale up to the entire set of strings.

I'm afraid that you're not going to be able to help us on this, sorry.

Thanks for your interest.
JBQ

Does that also apply to fixing translation errors, or to fixing display problems caused by translations? Frankly, the Hebrew translation of Android is a laughing stock.

Aside from texts that seem illiterate (my guess is that the translation team never saw those strings in the context in which they were displayed, and thus often misunderstood the tense in which the original English string was written). There is also some very painful to see lack of use of the plurals mechanism. It is painful to see "עוד 2 ימים" ("in 2 days") instead of "מחרתיים" ("the day after tomorrow"), or "עוד 2 שעות" ("in two hours") instead of "עוד שעתיים" (same meaning with a pair word).

Even more problematic are cases where the translation is okay, but a BiDi control character is really needed in order to keep the sentence from being completely broken when displayed with the %s substituted for an English word.

The most notable example of those are cases where the actual translation begins with an English word (such as the USB debugging connected sentence). This causes the automatic paragraph direction to view it as an English paragraph, and the entire sentence is completely jumbled. Adding a simple RLM (U200F) at the beginning of the translation will fix that.

So, in essence, what I'm asking is what level of "don't bother" are we at? Is the problem finding someone who understands the language to review the change, or are we at "no community translation fixes of any kind" policy?

Shachar

-- 
Shachar Shemesh
Lingnu Open Source Consulting Ltd.
http://www.lingnu.com

[Jean-Baptiste Queru]

In this instance, the root issue is the core BiDi support, which
wasn't ready enough in ICS.

Generally speaking, until that's resolved, it probably makes little
sense to focus too closely on the exact translations as they exist in
AOSP.

That being said, when looking at individual details, there might be
situations that can be identified where the existing code will cause
translation problems that can be anticipated and improved. Note
however that BiDi is an area that's receiving constant attention, and
since ICS is now quite far behind Google's internal master there's a
high risk that such changes could cause merge conflicts that'd make
them impossible to merge.

JBQ

[Jean-Baptiste Queru]

BiDi is one of those areas that's being worked on continuously, and
the related changes are extensive, which means that even at the points
in time where AOSP is closest to Google's internal master the gap is
still so large that it's essentially impossible for contributions to
make it across.

JBQ

On Tue, Jun 12, 2012 at 3:49 AM, David Kohen <koh...@gmail.com> wrote:
> Sachar and I have written patches for BiDi support for versions for a few
> years now (I started with 2.1, Sachar from 1.6 IIRC), sometimes the reason
> for the merge failing as I've seen from the following releases are
> variable/class name changes.
> I understand the need to make changes in the text presentation in the OS,
> but the lack of proper, full BiDi support in Android is hurting us all. I
> have 3 different devices from the same manufacturer and each one has a
> different level of BiDi support.
> This makes it near impossible to write a BiDi language app for Android.
> That also makes Nokia, Windows mobile and iPhone much more popular in Israel
> (and I assume in Arabic speaking countries as well) than Android, especially
> when comparing to other parts of the world.
>
> Isn't there a way to help us help you with this? Will writing a document
> explaining what we as Hebrew speaking developers need from the platform
> language support help?

>
> On Monday, June 11, 2012 6:55:40 PM UTC+3, Jean-Baptiste Queru wrote:
>>
>> In this instance, the root issue is the core BiDi support, which
>> wasn't ready enough in ICS.
>>
>> Generally speaking, until that's resolved, it probably makes little
>> sense to focus too closely on the exact translations as they exist in
>> AOSP.
>>
>> That being said, when looking at individual details, there might be
>> situations that can be identified where the existing code will cause
>> translation problems that can be anticipated and improved. Note
>> however that BiDi is an area that's receiving constant attention, and
>> since ICS is now quite far behind Google's internal master there's a
>> high risk that such changes could cause merge conflicts that'd make
>> them impossible to merge.
>>
>> JBQ
>>

[Shachar Shemesh]

Hi Jean,

I'm not sure I understand your answer correctly. I was asking about problems with the translations (l10n), and you seem to be answering about the BiDi engine (i18n). The ICS BiDi engine exhibits a very high level of Unicode conformance, and so I am hoping that it is stable enough to start tweaking the translations accordingly.

I would not claim that Android's BiDi support in ICS is complete (in fact, one year and one day ago I posted[1] about BiDi related APIs I'd like to see in Android, and that list is not yet adequately answered, IMHO), but as far as bare Unicode support we have come a LONG way, and as far as i18n ICS is the first Phone OS to offer support that is Unicode conforming, which means we finally have a fairly well understood standard to align ourselves with.

This is also the reason I do not agree with the gist of David's criticism (though I can certainly relate to the feelings that spurred it). I think his criticism is anchored on the current situation, with phones as old as Froyo still being sold in Israel (in fact, I think the Motorola Defy is still being sold with Eclair). Since this list is focused on the future, I actually think that the core BiDi engine in ICS is good enough, and changes should start focusing on other i18n related tasks, such as better resource selection and consolidation support (see [1] below), and BiDi localized animators (on which I can expand if necessary). I also think that this means that it's the perfect time to start improving the l10n aspects, by improving the translations so they are usable, and by mirroring the UI for the core Android applications.

Thanks,
Shachar

1 - https://groups.google.com/forum/#!msg/android-contrib/Kx76UpqDNNo/uW-ZqZuOB3EJ

On 06/11/2012 06:55 PM, Jean-Baptiste Queru wrote:

In this instance, the root issue is the core BiDi support, which
wasn't ready enough in ICS.

Generally speaking, until that's resolved, it probably makes little
sense to focus too closely on the exact translations as they exist in
AOSP.

That being said, when looking at individual details, there might be
situations that can be identified where the existing code will cause
translation problems that can be anticipated and improved. Note
however that BiDi is an area that's receiving constant attention, and
since ICS is now quite far behind Google's internal master there's a
high risk that such changes could cause merge conflicts that'd make
them impossible to merge.

JBQ

[Jean-Baptiste Queru]

There are 3 aspects that go together and that cannot be dissociated in
terms of supporting RTL languages:

-framework support.
-application support.
-translation.

All 3 need to evolve at the same time, because user-visible testing
can't distinguish between the issues from those 3 levels. At the same
time, those are dependent on one another: applications can't use BiDi
functionality until that's implemented in the framework, and
translating can only be approximate as long as apps don't have
BiDI-compatible base strings.

That's why things have been moving slowly and steadily at the same time.

To be honest, right now is not the time to make BiDi code changes in
AOSP, the gap with Google's internal master tree is just too big. Like
I explained above, handling translations via AOSP comes with some
heavy overhead, to the point where it's unrealistic to deal with more
than simple typos.

JBQ