wow, thanks for all the helpful replies, didn't realise I'd picked up on
something like this...
My thoughts on what have come up are that DM has an interesting solution by
incorporating the list into mods.d.tar.gz - especially given that the list
isn't essential, but simply an added extra useful bit, which is what Troy has
defined "mods.d.tar.gz" as being (given that it is optional & the mods.d
directory contains everything that is required).
The other thought I had was the suggestion from a week or so ago about the
versioning of the conf files... if the version numbers were X.Y.Z we could say
that a change in X or Y means there's a change in the text, requiring a
redownload of the entire text. However, a change in Z simply means that the
conf file has changed & so the user doesn't need to redownload the entire text
but simply grab the new conf file (generally less than 1K, but also available
in mods.d.tar.gz).
This would be useful for if we later on also want to add Feature=Paragraphs, or
whatever other tags we want to add that simply change the conf file (which is
how this suggestion came up last week)?
But would also mean we could silently update a conf file with a new language
code and as long as the front-end is keeping up-to-date with the ISO codes,
everything should work? :)
The simplest solution, which is what I'm about to go and do now, is to make the
front-ends use both the valid & deprecated language codes in their look-up
tables. :)
Thanks again for all the helpful (& enjoyably informative) responses :)
nic... :)
On 10/11/2009, at 1:45 PM, DM Smith wrote:
> On 11/09/2009 04:49 PM, Eeli Kaikkonen wrote:
>> On Mon, 9 Nov 2009, DM Smith wrote:
>>
>>> I don't know all the history, and what I know may be a bit faulty.
>>>
>> [<clip>]
>>
>> A bit faulty or not, it gives an explanation to the situation. However,
>> we have a more practical problem. We should be able keep the modules and
>> frontends in sync.
> I agree. Here are the issues that I see. There may be others and these might
> not be important.
> a) A module in a repository, we will assume, has a valid language code at the
> time it was created, but it might not be valid at a later date. We have seen
> several codes in the beta repository be obsoleted.
>
> A user may have one of these modules for a long time, not noticing an update
> that merely changes the language code to the current correct value.
>
> To solve this, the old code needs to be kept in so far as possible. (It might
> be re-assigned, but it appears that there is care taken to minimize or
> prevent that.)
>
> b) The release of updates of the SWORD engine takes longer than any of us
> wants. While we agree on frequent releases, we don't do that. This indicates
> that the we either tie language codes to what the engine knows or we find a
> different mechanism.
>
> c) 3rd party solutions have their own goals which might not align with module
> releases and updates. For example, they may not update as frequently as
> needed or they may only include currently valid codes.
>
> d) Some distributions of Linux have been notoriously slow in updating SWORD
> apps. There is no reason to expect that such an update mechanism can be
> relied upon.
>
> I see a couple of solutions, both based on CrossWire maintaining
> internationalized lists of module languages, current and past. This can be
> somewhat programmatic, grabbing the unique set of language codes, and
> constructing a filtered list of these languages (perhaps using the code I
> supplied earlier.)
>
> It could be place in mods.d.tar.gz or some other well known place for
> download. This is the only solution that I see that solves all the problems.
>
> JSword's solution is to try to keep current with the CrossWire production
> modules and hope that we encompass beta before they get into production. If
> we slip, we catalog the "new" languages as "Unknown", that is a code of
> "und." For most of our users, this accurately reflects their
> knowledge/opinion of the language. I think that is a fairly graceful fallback.
>
> In Him,
> DM
>
>
>> Whatever the module version, users should see only
>> the correct name of the language (or a language code if frontend is too
>> old to have the name for the language). Is it possible? How?
>>
>> Yours,
>> Eeli Kaikkonen (Mr.), Oulu, Finland
>> e-mail: [email protected] (with no x)
>>
>> _______________________________________________
>> sword-devel mailing list: [email protected]
>> http://www.crosswire.org/mailman/listinfo/sword-devel
>> Instructions to unsubscribe/change your settings at above page
>>
>
>
> _______________________________________________
> sword-devel mailing list: [email protected]
> http://www.crosswire.org/mailman/listinfo/sword-devel
> Instructions to unsubscribe/change your settings at above page
_______________________________________________
sword-devel mailing list: [email protected]
http://www.crosswire.org/mailman/listinfo/sword-devel
Instructions to unsubscribe/change your settings at above page
