--- Comment #16 from Papou <> ---

I'm afraid your message is unclear.
> I'm not opposed to having the language option that can be specified (Which is 
> already supported)
I don't understand.
Where is the documentation of that language option?
> My concerns with this proposal are:
> *It seems hackish (That's just a gut feeling, so perhaps not a fair 
> criticism) 
What is hackish?
- if it's the bug request, you'd better say it before someone uses his time to
please you (all)
- if it's the (open ended) way it's implemented, you'd better say how you would
have done it
> *It would be hard to adequately expose to the user which layers options are 
> available. The [[File:..]] syntax might then become very mysterious. (This is 
> probably my main worry) 
What simpler method do you devise to display a selection of named layers than
to give the list of their names?
Of course, even if docs disappeared in this era, the layers live best with an
explanation (which can be in layers).
> *There's possibly some issues with scalability related to how we store files. 
> (However that's an implementation detail, so perhaps not a fair criticism of 
> this bug as an "idea") 
I see some issues to discuss but not that.

What is mysterious is why people repeatedly discuss language support in a
project about layers selection support.  Even is that layer support also covers
languages and it's mentioned, subject closed.
It's like repeatedly speaking of Cobol in a Fortran project.
Both languages coexist and users choose what they find the most appropriate.
Layers support has a wider scope than and includes languages. That's all.

But if you really want to prompt my opinion, what I find a hack is the
It's a sub-product of an "if IE8 vs NS" like feature to adapt SVG code to some
Consequently it uses the LANG env variable of the GUI for the language of the
And hence it needs an "env LANG=" kludge to work correctly.
That would produce error messages in the language of the data.  Neat.
It cannot support more than one language at a time.
Plus, not regarding design, there is no editor support for it.
I don't want to discuss this any more.
The user should be informed of the alternative and he would choose.
> Luckily they could use your script on the client side to generate the 
> neccesary files :)
Brilliant idea ;-)  I'm going to write a script to upload 10 000 map files.
And I'll run it every time some detail changes in the map.

You are receiving this mail because:
You are the assignee for the bug.
You are on the CC list for the bug.
Wikibugs-l mailing list

Reply via email to