How to export translated messages from Launchpad? (Re: i18n test environment on Lauchpad staging.

[INADA Naoki]

>> 3) Using build_mo as python script is easy to implement auto-generation of
>> en.mo (pseudo translation for English-to-English language). That was proved
>> to be useful on some machines with mixed language settings, e.g. on Japanese
>> Windows XP with English user language we have LANG=en:ja, but if we don't
>> have en.mo then user will see all messages in Japanese.
>>

Thank you. I get why 'en.mo' is needed.

>
> Thanks for that.  I guessed it was 2.  I think Inada cut out the
> special handling of 'en' because we didn't know what it was for.
> Perhaps he should add it back in (with a comment ;-).
>
> Martin
>

I've done.
https://code.launchpad.net/~songofacandy/bzr/i18n-msgfmt-en/+merge/61807

FYI, I've modify msgfmt.py to support pass through mode (msgstr == msgid) and
didn't use msginit because I don't want to depends on such tool.
Building from source is common task and many non-developer users don't have
msginit nor msgfmt.


On Fri, May 20, 2011 at 5:56 PM, Martin Pool <mbp at canonical.com> wrote:
> On 20 May 2011 08:39, Alexander Belchenko <bialix at ukr.net> wrote:
>> Martin Pool пишет:
>>>
>>> On 16 May 2011 13:29, INADA Naoki <songofacandy at gmail.com> wrote:
>>>>>> If build_mo command is needed, I'll copy it from bzr-explorer.
>>>>
>>>> I've sent merge request adding build_mo command.
>>>> https://code.launchpad.net/~songofacandy/bzr/i18n-msgfmt/+merge/61082
>>>
>>> Thanks for that.
>>>
>>> Can you explain for me a bit about why the build_mo command is needed,
>>> rather than using externally available i18n tools?  Is it just that
>>> they are hard to install or get running on Windows?
>>
>> If this question is still valid, I may explain why I've implemented that for
>> QBzr and Explorer.
>>
>> 1) There is no problem with Windows, but you definitely want it to be in
>> some sort of Makefile. And because setup.py is also kind of Makefile it was
>> a very easy to implement that. Also with setup.py build_mo you have ability
>> to implement several options to customize its execution. Maybe in the end
>> it's not used actually.
>>
>> 2) Using setup.py it's easy to hook build_mo into general setup.py
>> build/install process, and therefore make sure translations will be
>> compiled/updated on build/install.
>>
>> 3) Using build_mo as python script is easy to implement auto-generation of
>> en.mo (pseudo translation for English-to-English language). That was proved
>> to be useful on some machines with mixed language settings, e.g. on Japanese
>> Windows XP with English user language we have LANG=en:ja, but if we don't
>> have en.mo then user will see all messages in Japanese.
>>
>> So, for me the item 2 is most useful, and item 3 is nice to have. Item 1 was
>> just in the vein of other i18n-related commands, like build_po (to collect
>> messages for translations).
>
> Thanks for that.  I guessed it was 2.  I think Inada cut out the
> special handling of 'en' because we didn't know what it was for.
> Perhaps he should add it back in (with a comment ;-).
>
> Martin
>



-- 
INADA Naoki  <songofacandy at gmail.com>