Developer forums (C::B DEVELOPMENT STRICTLY!) > Development
Generalizing programming language patterns in CodeBlocks
beqroson:
--- Quote from: stahta01 on November 11, 2013, 10:01:07 am ---Edit: Have you ever built CB from SVN source? If not, I suggest doing so.
--- End quote ---
Due to the fact that ollydbg only run 32-bit Windows, and the bug report I put on Berlios now is suspected to originate from 64-bit implementation, I am at the moment compiling from SVN. So, the suggestion is proceeded.
BTW, good point about the xml. If tinyXml does not support the UTF82, then you are right, it aggravates things considerably. I know eventually, to be usable, the UTF82 needs to be standardized. I expect the implementation of UTF82 to change several times before that happens, if it happens.
Alpha:
--- Quote from: beqroson on November 10, 2013, 05:03:58 pm ---However, a scenario where we would only have one global language, such as English? I am very pessimistic about that. What I see is that a language tend to accumulate a certain set of traits. With only one language, then we would by that theory have only one set of traits at a global level. Such a reduction of the wealth of the human culture would be... simply unacceptable.
--- End quote ---
Perhaps I spoke with too many absolutes. I was not arguing that English is a special language that everyone needs to learn.
However, for English based programming languages (specifically C/C++, which is Code::Blocks' main target), I consider using non-English identifier names and comments to be as confusing as mixing vocabulary from multiple languages to form a sentence.
That said, I do believe your idea has merit, as it sounds that your goal is lossless and bidirectional.
beqroson:
--- Quote from: Alpha on November 11, 2013, 04:15:27 pm ---as it sounds that your goal is lossless and bidirectional.
--- End quote ---
Yep, that is two aspects of the goal.
beqroson:
--- Quote from: Alpha on November 11, 2013, 04:15:27 pm ---I consider using non-English identifier names and comments to be as confusing as mixing vocabulary from multiple languages to form a sentence.
--- End quote ---
I believe that identifier names is fixable with an advanced translator mechanism. That can be a good win for the programmer. However, it demands specifying two identifier names for each identifier. Comments in another deal altogether. I have no clue about how comments could be fixed. And I do not think that there is a solution for comments that is simple enough to make it worth any effort.
As for comments I have been pondering using a huge database with pretranslated strings. But that is also a hassle if you must assemble all comments using templated text strings. Besided it means you need to connect to the database, update the database and so forth. Too cumbersome.
dmoore:
--- Quote from: beqroson on November 11, 2013, 05:18:35 pm ---
--- Quote from: Alpha on November 11, 2013, 04:15:27 pm ---I consider using non-English identifier names and comments to be as confusing as mixing vocabulary from multiple languages to form a sentence.
--- End quote ---
I believe that identifier names is fixable with an advanced translator mechanism. That can be a good win for the programmer. However, it demands specifying two identifier names for each identifier. Comments in another deal altogether. I have no clue about how comments could be fixed. And I do not think that there is a solution for comments that is simple enough to make it worth any effort.
As for comments I have been pondering using a huge database with pretranslated strings. But that is also a hassle if you must assemble all comments using templated text strings. Besided it means you need to connect to the database, update the database and so forth. Too cumbersome.
--- End quote ---
With both this stuff about comments and your UTF-82 talk, I think you are WAY overcomplicating things.
To me, the potential "win" here is to create set of standardized translation tables that translates programming language keywords and all of the exportable user defined tokens of the libs you care about (i.e. public classes, functions and variables of the libraries the user would use) to and from their foreign language equivalent. Comments, especially the doc strings for toolkits like wxWidgets, would be nice, but they aren't necessary to get a program to compile and dealing with them in the right way has to be part of a much larger translation effort.
To reiterate, you don't really need to integrate this into C::B to make your proof of concept. And you shouldn't because if it is useful to C::B users it will be useful to programmers more genrally. Why don't you start by writing a simple tool that takes the users foreign language source files (UTF-8), a speficified translation table, and outputs the english programming language equivalent (and vice versa). From there it would be easy enough to integrate into the GCC and other toolchains. Then turn it into a Library and IDEs will be able to take advantage of it too.
Navigation
[0] Message Index
[#] Next page
[*] Previous page
Go to full version