← Back to team overview

ubuntu-phone team mailing list archive

Re: Internationalizing scopes

 

Does this imply that the recommendation for .desktop files should also
change? If scopes are slow to load with .mo files, wouldn't the same
apply to .desktop files? Or maybe the question is what is "wrong" with
scopes that they can't be as efficient as .desktop files?

On 2014-04-15 20:14, Alex Chiang wrote:
> Hi David,
>
> I think those parameters are fine. They don't seem like they will
> materially add to any disk space / bandwidth requirements.
>
> Thanks.
>
> On Tue, Apr 15, 2014 at 9:51 AM, David Planella
> <david.planella@xxxxxxxxxx> wrote:
>> Hi Alex,
>>
>> I guess this will depend on the scope, but to give an example we can take
>> the click scope:
>>
>> - Scope code (translations shipped in .mo files): 15 messages
>> - Scope ini file (assuming we only want to translate the DisplayName key in
>> the ini file): 1 message
>>
>> So in terms of space, the inline translations approach has the disadvantage
>> of containing all translations in the ini file, whereas .mo files are
>> language-specific and we can choose which languages we want to install by
>> default. That said, ini files would only contain 1 translatable string (and
>> let's say 40 translated versions of that string).
>>
>> Let me know if this provides enough context.
>>
>> Cheers,
>> David.
>>
>>
>> On Tue, Apr 15, 2014 at 5:44 PM, Alex Chiang <achiang@xxxxxxxxxxxxx> wrote:
>>> On Tue, Apr 15, 2014 at 8:20 AM, David Planella
>>> <david.planella@xxxxxxxxxx> wrote:
>>>> We think using this option (inline translations in the ini files vs
>>>> reading
>>>> the translations from .mo files) is the best solution in terms of
>>>> performance when reading the list of scopes, but we'd like to hear other
>>>> comments/views too.
>>> What is the typical number of strings in a scope?
>>>
>>> My guess is fairly minimal, but would like to see some data.
>>>
>>> [The context of my question is to understand the disk size
>>> implications of inline translations...]
>>>
>>> Thanks.
>>


Attachment: signature.asc
Description: OpenPGP digital signature


Follow ups

References