Hi,
I just noticed the change[1] in wording of the set filetypes menu which was something that had (slightly) bothered me before, since I personally consider most of the scripting languages as programming languages as well. I'm not sure that the word "Compiled" is the best choice though, since it's kind of vague:
Is Vala a compiled language because it's compiled into C code? Is Python *not* compiled because it's compiled into bytecode? Is Java a compiled language?
I'm sure you can see what I mean, there's a lot of gray area using the term Compiled, since many languages can either be compiled to machine code, interpreted by a VM/runtime, compiled then interpreted, compiled to one format then another, compiled just in time, and so on. Unfortunately I don't really have much for alternative terms, but a few possibilities for better categorization could be:
- By the current categories, but putting filetypes under each one they fit in.
- By changing Scripting to Interpreted and then shuffling some filetypes around to reflect the way the languages are usually compiled/run.
- By the current categories, no change, since users will get used to where to find their languages pretty quickly.
- By Static vs Dynamic Typing
- By programming language paradigm (ie. oop, functional, etc), and then each programming language could fall below more than one menu item if they are multi-paradigm.
- By just Programming Languages, so that the Compiled and Scripting menus get merged. This could make the menu long/scroll. SciTE does this but with fewer languages.
- By alphabetic order, with a menu item for each letter of the alphabet unless no filetypes fall under a letter, then don't show it. This could be ugly in terms of code/i8n and appearances. IIRC another editor is doing this (Notepad++?).
There's also a few other quirks I've noticed in the 'Set Filetypes' menus:
- I generally wouldn't consider CSS a markup language, but it probably technically is. IMHO it would be more apt to put it under Miscellaneous.
- I believe LaTex, Markdown, and reStructuredText are Markup Languages.
- I don't know COBOL but I think it's a programming language isn't it?
- NSIS and CMake files, while domain-specific, are still scripting/programming languages.
- 'SQL Dump file' seems a bit odd, since it's a file containing language constructs and is "run" by the db engine, maybe it should be 'SQL file' or 'SQL source file'. I know a file containing SQL is often the result of dumping a database, but is it the only time you would end up with such a file?
- The wording 'Miscellaneous Languages' makes you think the contents of the submenu will contain (programming) Languages, but a config, diff, or gettext file for ex, doesn't really seem to be a language. The word 'Languages' could be removed from that menu item, which would imply that the contents of that menu will be 'Filetypes', more generally.
I could be wrong on these, they're just my observations. None of these are a big deal, but it was something I questioned probably even the first time I opened Geany and every time I select a filetype since.
P.S. Sorry if this previously been discussed, I'm not too sure how to search the geany-devel archives (no link on geany.org Mailing List), and google didn't seem to find anything.
Cheers, Matthew Brush
[1] http://git.geany.org/geany/commit/?id=856ea318e65f1b5cb038f04b7cd68dfc219b65...
I missed the the commit[1] before the previous one I mentioned, which is a pretty cool feature if it does what I think it does. Is this documented yet or is still a work in progress? Is it meant to let the user reorganize/rename the menu items in the Set Filetypes menu?
I notice the default filetypes_extensions.conf has 'Typoscript' in [Groups] which throws a warning on geany -v and that Genie and Scala show up under Compiled in the Set Filetypes Menu which is cool, but there's still a 'Custom Filetypes' menu item that pops out an empty menu.
Cheers, Matthew Brush
[1] http://git.geany.org/geany/commit/?id=6adfb3bcd604b33dc8da1a65eea78f0404bf7a...
On Thu, 28 Apr 2011 21:09:18 -0700 Matthew Brush mbrush@codebrainz.ca wrote:
I missed the the commit[1] before the previous one I mentioned, which is a pretty cool feature if it does what I think it does. Is this documented yet or is still a work in progress? Is it meant to let the user reorganize/rename the menu items in the Set Filetypes menu?
No, I should have been clearer. I edited the ChangeLog to read: Make filetype group *membership* configurable
I notice the default filetypes_extensions.conf has 'Typoscript' in [Groups] which throws a warning on geany -v and that Genie and Scala
Now removed, thanks.
show up under Compiled in the Set Filetypes Menu which is cool, but there's still a 'Custom Filetypes' menu item that pops out an empty menu.
I planned to remove that, which I've now done.
Regards, Nick
Hey Matthew,
[...]
I'm not sure that the word "Compiled" is the best choice though, since it's kind of vague:
Is Vala a compiled language because it's compiled into C code? Is Python *not* compiled because it's compiled into bytecode? Is Java a compiled language?
Java is if you use GCJ, Python is if you use PyPy, etc...
I agree, compiled is an irrelevant category, I suggest reverting to Programming.
[...]
- By the current categories, but putting filetypes under each one they fit
in.
- By changing Scripting to Interpreted and then shuffling some filetypes
around to reflect the way the languages are usually compiled/run.
- By the current categories, no change, since users will get used to where
to find their languages pretty quickly.
Vote for this but maybe with some minor shuffling.
By Static vs Dynamic Typing
By programming language paradigm (ie. oop, functional, etc), and then each
programming language could fall below more than one menu item if they are multi-paradigm.
No too subjective, you can do GObject in C so it must be an oop language eh?
- By just Programming Languages, so that the Compiled and Scripting menus
get merged. This could make the menu long/scroll. SciTE does this but with fewer languages.
Too long for small screens.
- By alphabetic order, with a menu item for each letter of the alphabet
unless no filetypes fall under a letter, then don't show it. This could be ugly in terms of code/i8n and appearances. IIRC another editor is doing this (Notepad++?).
It might be a fallback if we can't get anything better.
There's also a few other quirks I've noticed in the 'Set Filetypes' menus:
- I generally wouldn't consider CSS a markup language, but it probably
technically is. IMHO it would be more apt to put it under Miscellaneous.
Keep it with HTML since thats where its used.
- I believe LaTex, Markdown, and reStructuredText are Markup Languages.
Yup.
- I don't know COBOL but I think it's a programming language isn't it?
Well, it was in the 1970s, but I do remember someone asking about it recently so it must be still used.
- NSIS and CMake files, while domain-specific, are still
scripting/programming languages.
Should be with makefile.
[...]
- The wording 'Miscellaneous Languages' makes you think the contents of the
submenu will contain (programming) Languages, but a config, diff, or gettext file for ex, doesn't really seem to be a language. The word 'Languages' could be removed from that menu item, which would imply that the contents of that menu will be 'Filetypes', more generally.
So "miscellaneous filetypes" like "custom filetypes"
And to add one, why is R a script and all others in that menu source, since its the scripting menu?
And to comment on your next mail as well, even if the user can change it that doesn't mean we shouldn't try to get a sensible arrangement by default. Lots of people won't or won't know they can change it and will have the vague discontent that you have.
Cheers Lex
On Friday 29 April 2011 12:26:35 am Lex Trotman wrote:
Hey Matthew,
- I believe LaTex, Markdown, and reStructuredText are Markup
Languages.
Is there a (scintilla) lexer for reStructuredText? With a quick look at lexer names, I didn't see one.
With that same quick look, I came across the lexer LexTxt2tags.cxx and looked at that a little--it looks like some of the stuff there is (or could be easily adaptable for my lexer for Foswiki / TWiki. What is that lexer for--is there a markup language named Txt2tags?
Oh, ok, I googled, yes there is, and I guess I'll spend a little time (a few minutes) looking at that. (For Lex: it will save me from thinking about lexing UTF-8, recursive descent parsers, switch / case statements, and if / else chains ;-)
- I don't know COBOL but I think it's a programming language isn't
it?
Well, it was in the 1970s, but I do remember someone asking about it recently so it must be still used.
Actually, it was also in the 1950s. Or, at least, the first specification was completed in December, 1959, and it is still used, a lot--there is a lot of legacy code out there. But not (used) by me! ;-)
And, just for the record, no, I'm not that old. I'm actually the same age as Jack Benny. (Should I explain the joke / humor? Jack Benny was a comedian who, whenever he was asked his age, claimed to be 29.)
Randy Kramer
Is there a (scintilla) lexer for reStructuredText? With a quick look at lexer names, I didn't see one.
No, the ReST filetype does not have syntax highlighting.
With that same quick look, I came across the lexer LexTxt2tags.cxx and looked at that a little--it looks like some of the stuff there is (or could be easily adaptable for my lexer for Foswiki / TWiki. What is that lexer for--is there a markup language named Txt2tags?
Oh, ok, I googled, yes there is, and I guess I'll spend a little time (a few minutes) looking at that. (For Lex: it will save me from thinking about lexing UTF-8, recursive descent parsers, switch / case statements, and if / else chains ;-)
Yes txt2tags and markdown are both lightweight markup languages, similar to wiki markup but of course annoyingly different in detail, just like wikis.
Cheers Lex
On Fri, 29 Apr 2011 14:26:35 +1000 Lex Trotman elextr@gmail.com wrote:
And to add one, why is R a script and all others in that menu source, since its the scripting menu?
Now changed to source file.
Regards, Nick
On Thu, 28 Apr 2011 20:13:05 -0700 Matthew Brush mbrush@codebrainz.ca wrote:
Hi,
I just noticed the change[1] in wording of the set filetypes menu which was something that had (slightly) bothered me before, since I personally consider most of the scripting languages as programming languages as well.
This is why I changed it, scripting is programming.
I'm not sure that the word "Compiled" is the best choice though, since it's kind of vague:
Is Vala a compiled language because it's compiled into C code? Is Python *not* compiled because it's compiled into bytecode? Is Java a compiled language?
I'm sure you can see what I mean, there's a lot of gray area using the term Compiled, since many languages can either be compiled to machine code, interpreted by a VM/runtime, compiled then interpreted, compiled to one format then another, compiled just in time, and so on.
Obviously all source code is compiled at some point. The Compiled group all have one thing in common - separate compilation is normally required before execution. This is still true for Java. Python compiles on the fly, and is obviously thought of as a scripting language rather than a compiled one.
Unfortunately I don't really have much for alternative terms, but a few possibilities for better categorization could be:
- By the current categories, but putting filetypes under each one they
fit in.
that depends on how you interpret compiled.
- By changing Scripting to Interpreted and then shuffling some filetypes
around to reflect the way the languages are usually compiled/run.
D can be interpreted or compiled, but not scripting. It's normally compiled, but the point is this categorisation is not much better than the status quo.
- By the current categories, no change, since users will get used to
where to find their languages pretty quickly.
- By Static vs Dynamic Typing
Some are both e.g. Haxe.
- By programming language paradigm (ie. oop, functional, etc), and then
each programming language could fall below more than one menu item if they are multi-paradigm.
I think this is too complicated.
- By just Programming Languages, so that the Compiled and Scripting
menus get merged. This could make the menu long/scroll. SciTE does this but with fewer languages.
I really don't see what's wrong with the current separation, after a first glance at each it should be easy to understand.
- By alphabetic order, with a menu item for each letter of the alphabet
unless no filetypes fall under a letter, then don't show it. This could be ugly in terms of code/i8n and appearances. IIRC another editor is doing this (Notepad++?).
filetype names are not translated IIRC. Not sure this proposal is better.
There's also a few other quirks I've noticed in the 'Set Filetypes' menus:
- I generally wouldn't consider CSS a markup language, but it probably
technically is. IMHO it would be more apt to put it under Miscellaneous.
I agree, I think there is little overlap with CSS and document languages like HTML.
- I believe LaTex, Markdown, and reStructuredText are Markup Languages.
Good point also, and txt2tags.
I don't know COBOL but I think it's a programming language isn't it?
NSIS and CMake files, while domain-specific, are still
scripting/programming languages.
Ok.
- 'SQL Dump file' seems a bit odd, since it's a file containing language
constructs and is "run" by the db engine, maybe it should be 'SQL file' or 'SQL source file'. I know a file containing SQL is often the result of dumping a database, but is it the only time you would end up with such a file?
- The wording 'Miscellaneous Languages' makes you think the contents of
the submenu will contain (programming) Languages, but a config, diff, or gettext file for ex, doesn't really seem to be a language. The word 'Languages' could be removed from that menu item, which would imply that the contents of that menu will be 'Filetypes', more generally.
I could be wrong on these, they're just my observations. None of these are a big deal, but it was something I questioned probably even the first time I opened Geany and every time I select a filetype since.
Agree also on all these points.
Regards, Nick
On Fri, 29 Apr 2011 17:06:46 +0100 Nick Treleaven nick.treleaven@btinternet.com wrote:
On Thu, 28 Apr 2011 20:13:05 -0700 Matthew Brush mbrush@codebrainz.ca wrote:
filetype names are not translated IIRC.
Although the *title* is translated, which is what we were talking about (oops).
There's also a few other quirks I've noticed in the 'Set Filetypes' menus:
- I generally wouldn't consider CSS a markup language, but it probably
technically is. IMHO it would be more apt to put it under Miscellaneous.
I agree, I think there is little overlap with CSS and document languages like HTML.
As Lex and Enrico probably prefer it in the Markup group, I decided to leave it. It may be more practical there.
- I believe LaTex, Markdown, and reStructuredText are Markup Languages.
Good point also, and txt2tags.
And YAML. Now done.
I don't know COBOL but I think it's a programming language isn't it?
NSIS and CMake files, while domain-specific, are still
scripting/programming languages.
- 'SQL Dump file' seems a bit odd, since it's a file containing language
constructs and is "run" by the db engine, maybe it should be 'SQL file' or 'SQL source file'.
- The wording 'Miscellaneous Languages' makes you think the contents of
the submenu will contain (programming) Languages, but a config, diff, or gettext file for ex, doesn't really seem to be a language. The word 'Languages' could be removed from that menu item, which would imply that the contents of that menu will be 'Filetypes', more generally.
These all done also. Thanks for the suggestions.
Regards, Nick
On 04/29/11 09:34, Nick Treleaven wrote:
On Fri, 29 Apr 2011 17:06:46 +0100 Nick Treleavennick.treleaven@btinternet.com wrote:
On Thu, 28 Apr 2011 20:13:05 -0700 Matthew Brushmbrush@codebrainz.ca wrote:
- I generally wouldn't consider CSS a markup language, but it probably
technically is. IMHO it would be more apt to put it under Miscellaneous.
I agree, I think there is little overlap with CSS and document languages like HTML.
As Lex and Enrico probably prefer it in the Markup group, I decided to leave it. It may be more practical there.
Agree. Lex's point is true, and I think it truly is a markup language, according to Wiki anyway.
- I believe LaTex, Markdown, and reStructuredText are Markup Languages.
Good point also, and txt2tags.
And YAML. Now done.
Heh. I actually had put YAML in the above list, but I removed it while revising my message before sending because:
1) It's an acronym for 'YAML Ain't Markup Language'. 2) I've only ever used it (or seen it used) as a configuration or serialization format, rather than for marking anything up.
I'm not saying it doesn't fit best under Markup, just why I didn't list it :)
I'm gonna try it out later tonight. Thanks
Cheers, Matthew Brush
On Fri, 29 Apr 2011 23:23:45 -0700 Matthew Brush mbrush@codebrainz.ca wrote:
- I believe LaTex, Markdown, and reStructuredText are Markup Languages.
Good point also, and txt2tags.
And YAML. Now done.
Heh. I actually had put YAML in the above list, but I removed it while revising my message before sending because:
- It's an acronym for 'YAML Ain't Markup Language'.
- I've only ever used it (or seen it used) as a configuration or
serialization format, rather than for marking anything up.
I'm not saying it doesn't fit best under Markup, just why I didn't list it :)
Ok, reverted that change. I remembered when it was Yet Another ML.
Regards, Nick
On 04/29/11 09:06, Nick Treleaven wrote:
On Thu, 28 Apr 2011 20:13:05 -0700 Matthew Brushmbrush@codebrainz.ca wrote:
I'm sure you can see what I mean, there's a lot of gray area using the term Compiled, since many languages can either be compiled to machine code, interpreted by a VM/runtime, compiled then interpreted, compiled to one format then another, compiled just in time, and so on.
Obviously all source code is compiled at some point. The Compiled group all have one thing in common - separate compilation is normally required before execution. This is still true for Java. Python compiles on the fly, and is obviously thought of as a scripting language rather than a compiled one.
I guess I just don't see much difference between a .class/.jar file and a .pyc/.egg at this level. Python is typically not compiled on the fly, it's compiled once, and then the bytecode is run many times, it only compiles on the fly when there's no up to date .pyc file. Usually you'll have compiled .pyc/.pyx files in your system directories, PATH, etc., AFAIK.
A (probably bad) analogy would be like grouping computers by "those with a hard drive" and "those which run Windows". Which group does a laptop fit in? A desktop? A server? A thin client?
- By the current categories, but putting filetypes under each one they
fit in.
that depends on how you interpret compiled.
This is how I feel about the current grouping.
- By just Programming Languages, so that the Compiled and Scripting
menus get merged. This could make the menu long/scroll. SciTE does this but with fewer languages.
I really don't see what's wrong with the current separation, after a first glance at each it should be easy to understand.
The same could be said about the old terminology, however inaccurate.
- By alphabetic order, with a menu item for each letter of the alphabet
unless no filetypes fall under a letter, then don't show it. This could be ugly in terms of code/i8n and appearances. IIRC another editor is doing this (Notepad++?).
[...]
Not sure this proposal is better.
It's the only concrete grouping, thought I don't necessarily desire it like this for obvious reasons.
Anyway, it's not such a big deal, and Compiled is more accurate than Programming, so thanks for addressing it.
Cheers, Matthew Brush
On Sat, 30 Apr 2011 02:39:09 -0700 Matthew Brush mbrush@codebrainz.ca wrote:
On 04/29/11 09:06, Nick Treleaven wrote:
On Thu, 28 Apr 2011 20:13:05 -0700 Matthew Brushmbrush@codebrainz.ca wrote:
I'm sure you can see what I mean, there's a lot of gray area using the term Compiled, since many languages can either be compiled to machine code, interpreted by a VM/runtime, compiled then interpreted, compiled to one format then another, compiled just in time, and so on.
Obviously all source code is compiled at some point. The Compiled group all have one thing in common - separate compilation is normally required before execution. This is still true for Java. Python compiles on the fly, and is obviously thought of as a scripting language rather than a compiled one.
I guess I just don't see much difference between a .class/.jar file and a .pyc/.egg at this level. Python is typically not compiled on the fly, it's compiled once, and then the bytecode is run many times, it only compiles on the fly when there's no up to date .pyc file. Usually you'll have compiled .pyc/.pyx files in your system directories, PATH, etc., AFAIK.
Yes, the result is cached, kind of. But it is usually done when the user wants to run a Python program, the user doesn't compile modules first, unlike Java.
A (probably bad) analogy would be like grouping computers by "those with a hard drive" and "those which run Windows". Which group does a laptop fit in? A desktop? A server? A thin client?
That is unfair. Compiled has a technical meaning which you are using, but languages that don't auto-compile is a distinct category and recognisable by users.
Anyway, it's not such a big deal, and Compiled is more accurate than Programming, so thanks for addressing it.
Ok. If others mostly dislike the current grouping and can agree on a better alternative (one without long menus) I don't mind switching.
Regards, Nick
Ok. If others mostly dislike the current grouping and can agree on a better alternative (one without long menus) I don't mind switching.
Hi Nick, I think the grouping is not too bad, although as I said before I don't like "Compiled" as a name, especially when its compiled vs scripting. But I don't mind strongly, its up to general opinion.
Cheers Lex
Regards, Nick _______________________________________________ Geany-devel mailing list Geany-devel@uvena.de https://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
On Sat, 30 Apr 2011 22:22:52 +1000 Lex Trotman elextr@gmail.com wrote:
Ok. If others mostly dislike the current grouping and can agree on a better alternative (one without long menus) I don't mind switching.
Hi Nick, I think the grouping is not too bad, although as I said before I don't like "Compiled" as a name, especially when its compiled vs scripting. But I don't mind strongly, its up to general opinion.
I think Compiled is more differentiated than Programming when compared to Scripting. But any suggestions are welcome.
Regards, Nick
On Sat, 30 Apr 2011 13:36:45 +0100 Nick Treleaven nick.treleaven@btinternet.com wrote:
Hi Nick, I think the grouping is not too bad, although as I said before I don't like "Compiled" as a name, especially when its compiled vs scripting. But I don't mind strongly, its up to general opinion.
I think Compiled is more differentiated than Programming when compared to Scripting. But any suggestions are welcome.
Maybe Compiled/Interpreted would have been Ok actually. But for now I decided to just revert to Programming/Scripting.
Regards, Nick
On 1 May 2011 01:12, Nick Treleaven nick.treleaven@btinternet.com wrote:
On Sat, 30 Apr 2011 13:36:45 +0100 Nick Treleaven nick.treleaven@btinternet.com wrote:
Hi Nick, I think the grouping is not too bad, although as I said before I don't like "Compiled" as a name, especially when its compiled vs scripting. But I don't mind strongly, its up to general opinion.
I think Compiled is more differentiated than Programming when compared to Scripting. But any suggestions are welcome.
Maybe Compiled/Interpreted would have been Ok actually. But for now I decided to just revert to Programming/Scripting.
Ok.
I guess there isn't any real perfect solution to this, just to explain I see Programming/Scripting as being more user oriented than compiled/interpreted which is specific implementation oriented, and as has been said there can be lots of implementations.
Not that everyone might agree with the current division, I'm sure the folks at Ericsson who are programming telephone switches in Erlang might see it as more than a scripting language :-) But programming is too long already.
Cheers Lex
Regards, Nick _______________________________________________ Geany-devel mailing list Geany-devel@uvena.de https://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
On Sun, 1 May 2011 10:46:59 +1000 Lex Trotman elextr@gmail.com wrote:
Maybe Compiled/Interpreted would have been Ok actually. But for now I decided to just revert to Programming/Scripting.
Ok.
I guess there isn't any real perfect solution to this, just to explain I see Programming/Scripting as being more user oriented than compiled/interpreted which is specific implementation oriented, and as has been said there can be lots of implementations.
Agree.
Not that everyone might agree with the current division, I'm sure the folks at Ericsson who are programming telephone switches in Erlang might see it as more than a scripting language :-) But programming is too long already.
I think the Scripting group could be thought of as a subset of Programming. That's not to suggest it be a submenu though ;-)
Regards, Nick
On 04/30/11 05:36, Nick Treleaven wrote:
On Sat, 30 Apr 2011 22:22:52 +1000 Lex Trotmanelextr@gmail.com wrote:
Ok. If others mostly dislike the current grouping and can agree on a better alternative (one without long menus) I don't mind switching.
Hi Nick, I think the grouping is not too bad, although as I said before I don't like "Compiled" as a name, especially when its compiled vs scripting. But I don't mind strongly, its up to general opinion.
I think Compiled is more differentiated than Programming when compared to Scripting. But any suggestions are welcome.
I just had another idea on this; High-level languages and/vs Low-Level languages. Maybe this is a good delimiter/term to differentiate between them?
Cheers, Matthew Brush
On 1 May 2011 14:08, Matthew Brush mbrush@codebrainz.ca wrote:
On 04/30/11 05:36, Nick Treleaven wrote:
On Sat, 30 Apr 2011 22:22:52 +1000 Lex Trotmanelextr@gmail.com wrote:
Ok. If others mostly dislike the current grouping and can agree on a better alternative (one without long menus) I don't mind switching.
Hi Nick, I think the grouping is not too bad, although as I said before I don't like "Compiled" as a name, especially when its compiled vs scripting. But I don't mind strongly, its up to general opinion.
I think Compiled is more differentiated than Programming when compared to Scripting. But any suggestions are welcome.
I just had another idea on this; High-level languages and/vs Low-Level languages. Maybe this is a good delimiter/term to differentiate between them?
For me that would put C in an item by itself, and all the rest together :-)
I don't even know what *you* mean by high level vs low level, but for me most of these languages could argue as high level, even C (if you argued long enough).
Cheers Lex
Cheers, Matthew Brush _______________________________________________ Geany-devel mailing list Geany-devel@uvena.de https://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
On 1 May 2011 14:35, Lex Trotman elextr@gmail.com wrote:
On 1 May 2011 14:08, Matthew Brush mbrush@codebrainz.ca wrote:
On 04/30/11 05:36, Nick Treleaven wrote:
On Sat, 30 Apr 2011 22:22:52 +1000 Lex Trotmanelextr@gmail.com wrote:
Ok. If others mostly dislike the current grouping and can agree on a better alternative (one without long menus) I don't mind switching.
Hi All,
As I have said before I don't care strongly about the current breakup, but several people seem to. After some thought I feel that this is likely to be that the breakup is subjective.
But the only objective breakup I can think of is alphabetic, with submenus a-k, l-z or whatever arrangement gives nice menus. Now as someone else said this raises questions of localisation, and here my ignorance of other languages started started to show. Having failed to find a good answer on Google I now throw the question to the worldwide Geany dev list:
How do you normally handle computer language names in your locale?
In locales with a Latin alphabet (ie ASCII is a subset, eg French, German) do you a) leave the name as is, b) if the name is a word (lisp, scheme, racket) do you translate it to the equivalent word c) are acronyms the acronym of the translation of the phrase they are based on
In locales with a non-latin alphabet (eg Cyrillic, Greek) do you a)leave the name in ASCII, b) translate it character by character to the nearest ones in your alphabet (assuming such a translation exists) c) then if it forms a word do you translate that, and d) what about acronyms.
And what about non-alphabetic languages if anyone is using Geany in such a locale (there is a Japanese translation I think, but is it to an alphabetic script or an ideographic script).
Oh and where things are not translated, what do you do if the name/acronym forms a rude/derogatory word in your locale?
Cheers Lex
Hi,
As I have said before I don't care strongly about the current breakup,
I don't really care neither, but... (read ahead)
but several people seem to. After some thought I feel that this is likely to be that the breakup is subjective.
But the only objective breakup I can think of is alphabetic, with submenus a-k, l-z or whatever arrangement gives nice menus.
...I'm not sure a too large refactoring of these menus is really a good thing for users that may be used to the current splitting, but I admit that the current splitting is quite arbitrary (though I don't know of an entry I better place somewhere else... but I don't know all the languages we have).
Now as someone else said this raises questions of localisation, and here my ignorance of other languages started started to show. Having failed to find a good answer on Google I now throw the question to the worldwide Geany dev list:
How do you normally handle computer language names in your locale?
In locales with a Latin alphabet (ie ASCII is a subset, eg French, German) do you a) leave the name as is, b) if the name is a word (lisp, scheme, racket) do you translate it to the equivalent word c) are acronyms the acronym of the translation of the phrase they are based on
Answer from me, a French guy: we don't translate such names. Scheme is still Scheme, Lisp still Lisp, Caml still Caml, XML is not LBX, etc. So there's no problem for french.
And IIRC, we don't translate these names currently in Geany, but only something like "%s source file". But I agree that even if it's OK for names, it may be not for alphabetical grouping, no idea.
[...]
Oh and where things are not translated, what do you do if the name/acronym forms a rude/derogatory word in your locale?
I never seen such case, so I can't tell... but I guess we'd keep it and laugh at it :D
Cheers, Colomban