Re: [Gramps-devel] Attention translators - refactoring proposal the _date_XX.py infra

[Vassilii K. <vas...@ta...>]

On 17.08.2013 18:40, John Ralls wrote:
>
> On Aug 17, 2013, at 3:36 AM, Vassilii Khachaturov <vas...@ta... 
> <mailto:vas...@ta...>> wrote:
>
>> [SNIP]
>>
>>
>> So, instead of the previous proposal for the Backward English example
>>
>>     msgid "nominative|genitive|alternative|...||January"
>>     msgstr "yraunaJ|yraunaJJJ|eiraunaJ"
>>
>> we would now have
>>
>>     msgid "localized inflections of lexeme|January"
>>     msgstr "nom=yraunaJ|gen=yraunaJJJ"
>>
>> and
>>
>>     msgid "alternative names|January"
>>     msgstr "eiraunaJ"
>>
>> Technically it would still be possible for a translator to do smth like
>>
>>     msgid "localized inflections of lexeme|January"
>>     msgstr "nom=yraunaJ|gen=yraunaJJJ|alt1=eiraunaJ"
>>
>> but this is terribly wrong, as the alternative is not really an 
>> inflection of the same lexeme.
>>
>> [SNIP]
>
> Interesting. I thought that there would turn out to be more 
> inflections required.
>
> Alternate names are for the parser rather than the displayer. In order 
> for them to be properly recognized they too
> will have to be presented in every possible inflection, but maybe they 
> don't need to be labelled with which one.
Yes, this was exactly my intention. Whatever alternatives the translator 
was specifying manually up to now via patching the months_to_int[] 
dictionary, he will now do via the relevant alternative names msgstr. So 
Jerome will have something like this in the fr.po

     msgid "alternative names|January"
     msgstr "janvier|januaris|januarii|januarius"

instead of this currently in _date_fr.py:
     # Add common latin

     month_to_int[u"januaris"] = 1
     month_to_int[u"januarii"] = 1
     month_to_int[u"januarius"] = 1

And it's perfectly fine not to label the Latin inflections because you 
don't really care what inflection the user gave as long as you recognize 
it in the parser...

> Wouldn't it be sufficient to present a tuple of possibilities for the 
> parser to iterate over?  One way to build a parse dictionary would be 
> to  use gettext rather than lexgettext on the lexeme string and 
> extract the inflections into a tuple, do the same with
> the alternatives list, and combine the two, and populate the 
> dictionary with the result as keys and the month number as value.
Yep. Plus the prefix-recognition code that I have added in the last 
patch. Maybe I should later refactor it into a separate routine...

VKh