Showing posts with label computers. Show all posts
Showing posts with label computers. Show all posts
The World
I made the following map - it is not very scientific, and was done by eye. This is a map of browser preference by country. It is very interesting! Internet Explorer (Blue), Firefox (Orange) and Opera (Red) are the only browsers with a majority in any one country. Chrome shows up as a major contender in a few countries, but is never the top browser (yet).
Labels:
censorship,
choice,
computers,
economics,
free will,
Freedom,
Government,
humans,
Invention,
Liberty,
politics,
software,
Technology
Electronic Arts and the Shareholders
I've been reading Twenty Sided by Shamus Young, who really gets on EA's case about making stupid decisions (DRM, bad games, unfinished games, stupid games, DRM, etc). He blames most of those decisions on EA's board of directors wanting to please the shareholders. (the idiocy of that whole system is a topic for another time)
So, my idea as I was waking up this morning - what if you got a collective of gamers together, and each of them bought at least one share in the company (preferably much more, as shares are only $20 right now). If they got enough members, they would become a major shareholder in the company, and be able to influence the way the company is run by more than just their buying habits.
Anyone out there an expert on this type of thing? If you got only 10,000 gamers to join with $100 investment, you would have control over $1,000,000 .. would EA listen if you threatened to sell it all? EA has to listen to their shareholders, but their shareholders probably aren't going to be the ones buying the games - and could care less about the quality - they are just there to look after their money, and if EA is making money, it's all good. But, the gamers are looking for quality, which would also lead to more money. It's how all of these companies got started, and now that they have made it, they push their way through the competition with marketing, even if their games suck.
So, my idea as I was waking up this morning - what if you got a collective of gamers together, and each of them bought at least one share in the company (preferably much more, as shares are only $20 right now). If they got enough members, they would become a major shareholder in the company, and be able to influence the way the company is run by more than just their buying habits.
Anyone out there an expert on this type of thing? If you got only 10,000 gamers to join with $100 investment, you would have control over $1,000,000 .. would EA listen if you threatened to sell it all? EA has to listen to their shareholders, but their shareholders probably aren't going to be the ones buying the games - and could care less about the quality - they are just there to look after their money, and if EA is making money, it's all good. But, the gamers are looking for quality, which would also lead to more money. It's how all of these companies got started, and now that they have made it, they push their way through the competition with marketing, even if their games suck.
My Research System
Sort of in response to a recent comment, I would like to share with you my method of studying the scriptures.
My Tools:
Let's say I want to know more about the word translated charity in most English New Testaments. First, I would look up the word charity on Folio or my LDS bible, depending on how high-tech I wanted to get (software vs a book). This would give me every instance of the word charity in the new testament.
Next, if I was using Folio, I would click on one of the words and have it look up the strong's # for me. This would show me the greek word that was translated to charity. Next, I would compare the search results for charity with the list of instances of that greek word being translated charity and see if there are any places where that word is not translated charity, or charity was not translated from that word. Then I would do the same for any word that comes up an an anomaly. In a word processor (rather than the built-in note taker, which works, but I like a real word processor better) I would take notes on what I find. I would also make sure to write down the root of the word that is being used, as well as related words and so on.
To obtain the same results, I could also use my KJV bible's concordance to find instances of the word charity, then look them up on the KJV with Strong's Concordance website. I don't own a physical Strong's concordance, or I could also use that. The process is about the same otherwise.
If I really wanted to go low-tech, I could also use my interlinear greek / english new testament and compare the greek words. I do not speak greek, so I would only come out with a list of greek words minus their meanings.
Let's say that I wanted to study the Jewish idea of heaven. First, using either my concordance or Folio, I would look up where the word heaven is used, or I could just use my memory to start with. Then, I could look in my Jewish study bible and read its commentary for each instance (as well as the text itself, of course). Next, using Folio, I would search for the word heaven in my Legends of the Jews by Ginzberg. That would bring me to various stories and extrapolations about the jewish idea of heaven. I could do the same for the Talmud, Midrash and other jewish commentaries.
What if I wanted to know the origin of Baptism? First, I would look in the Catholic Encyclopedia, or Wikipedia and see what they had to say. I would look at the sources where possible. I would read references to baptism in the scriptures. I would study the origin of the word baptism, and see which other cultures have ritual cleansing, and read about those as well. If I wanted to do extensive research on a topic, I would use TomBoy Notes, which is like a personal wiki, to keep track of all my different pieces of data.
When I study, I cannot use just one book or piece of software. No single tool exists that can do everything that I want to do. And, even if there was one, I wouldn't want to rely on ONE source for all of my knowledge, it would be too easy for me to be lazy and not look outside that box for more information.
My Tools:
- an LDS KJV bible (standard translation with an extensive topical index and footnotes)
- an Oxford Jewish Study Bible published by JPS
- an English-Hebrew Tanakh published by JPS
- an interlinear Greek-English New Testament
- The Power New Testament A Hebrew Roots NT
- Other Bible translations: New World Translation, Young's Literal Translation
- Folio Bound VIEWS 3, an old Information Database System
- The Hebrew Interlinear Bible
- TomBoy notes
- Open Office Writer (A word Processor)
- The Sacred Text Archive
- The Catholic Encyclopedia
- Parallel Hebrew Old Testament
- Parallel Greek New Testament
- KJV with Strong's Concordance, Greek and Hebrew
- Strong's Hebrew and Greek Dictionary
- Hebrew Transliteration Tool
- Wikipedia
- Google
Let's say I want to know more about the word translated charity in most English New Testaments. First, I would look up the word charity on Folio or my LDS bible, depending on how high-tech I wanted to get (software vs a book). This would give me every instance of the word charity in the new testament.
Next, if I was using Folio, I would click on one of the words and have it look up the strong's # for me. This would show me the greek word that was translated to charity. Next, I would compare the search results for charity with the list of instances of that greek word being translated charity and see if there are any places where that word is not translated charity, or charity was not translated from that word. Then I would do the same for any word that comes up an an anomaly. In a word processor (rather than the built-in note taker, which works, but I like a real word processor better) I would take notes on what I find. I would also make sure to write down the root of the word that is being used, as well as related words and so on.
To obtain the same results, I could also use my KJV bible's concordance to find instances of the word charity, then look them up on the KJV with Strong's Concordance website. I don't own a physical Strong's concordance, or I could also use that. The process is about the same otherwise.
If I really wanted to go low-tech, I could also use my interlinear greek / english new testament and compare the greek words. I do not speak greek, so I would only come out with a list of greek words minus their meanings.
Let's say that I wanted to study the Jewish idea of heaven. First, using either my concordance or Folio, I would look up where the word heaven is used, or I could just use my memory to start with. Then, I could look in my Jewish study bible and read its commentary for each instance (as well as the text itself, of course). Next, using Folio, I would search for the word heaven in my Legends of the Jews by Ginzberg. That would bring me to various stories and extrapolations about the jewish idea of heaven. I could do the same for the Talmud, Midrash and other jewish commentaries.
What if I wanted to know the origin of Baptism? First, I would look in the Catholic Encyclopedia, or Wikipedia and see what they had to say. I would look at the sources where possible. I would read references to baptism in the scriptures. I would study the origin of the word baptism, and see which other cultures have ritual cleansing, and read about those as well. If I wanted to do extensive research on a topic, I would use TomBoy Notes, which is like a personal wiki, to keep track of all my different pieces of data.
When I study, I cannot use just one book or piece of software. No single tool exists that can do everything that I want to do. And, even if there was one, I wouldn't want to rely on ONE source for all of my knowledge, it would be too easy for me to be lazy and not look outside that box for more information.
Labels:
bible,
computers,
hebrew,
jewish,
religion,
scriptures,
self-sufficiency,
software,
Technology,
website
TomeCat
Since 2000 I have personally been working on a program that I call TomeCat. It is just a very basic text reader built with PHP and MySQL. I'm not a programmer by any means, and so the going has been very slow. After my run-in with Libronix (see previous post), I have some new ideas tinkering around in my brain (see other previous post). I'd like to see some of those ideas incorporated into TomeCat.
TomeCat is running on a database right now. Every chapter in the book is a separate entry in the chapter table. This is fine, except that I want to be able to quickly create books, and copying and pasting chapters into a database isn't my idea of fun. It also brought up the question of embedded media such as images, audio, movies, links and so on. I would have to manually add code to the pristine database driven text files. That was kind of bad!
As a in-between step from TomeCat in a web browser to TomeCat as a desktop app, I think XML files are a better way to go. The texts could be converted to simple XML documents with markup tags like book, title, author, chapter, section, img, map, verse, p, audio, crossreference, link and so on. A browser would be able to read this, as well as a desktop app. This would let me get the markup straight before I leap off of the platform that I'm comfortable with.
A couple hurdles that I'm not quite sure how to jump over are how to show the existing table of contents, with separate pages for each chapter. I think this would be accomplished by searching for tags, and then replacing them with functions .. not sure.
The code would have to be manually added (although the basics could be parsed with a custom tool), which is kind of sad, but eventually, I know an editor could be created that took 'What You Mean Is What You Get' and turned it into properly formatted xml.
The reasons I want to eventually go with a desktop app are:
TomeCat is running on a database right now. Every chapter in the book is a separate entry in the chapter table. This is fine, except that I want to be able to quickly create books, and copying and pasting chapters into a database isn't my idea of fun. It also brought up the question of embedded media such as images, audio, movies, links and so on. I would have to manually add code to the pristine database driven text files. That was kind of bad!
As a in-between step from TomeCat in a web browser to TomeCat as a desktop app, I think XML files are a better way to go. The texts could be converted to simple XML documents with markup tags like book, title, author, chapter, section, img, map, verse, p, audio, crossreference, link and so on. A browser would be able to read this, as well as a desktop app. This would let me get the markup straight before I leap off of the platform that I'm comfortable with.
A couple hurdles that I'm not quite sure how to jump over are how to show the existing table of contents, with separate pages for each chapter. I think this would be accomplished by searching for tags, and then replacing them with functions .. not sure.
The code would have to be manually added (although the basics could be parsed with a custom tool), which is kind of sad, but eventually, I know an editor could be created that took 'What You Mean Is What You Get' and turned it into properly formatted xml.
The reasons I want to eventually go with a desktop app are:
- The life of the product is extended past the time when I want a server running for it.
- Right click and multiple window interfaces, without using "AJAX". This also means it will work even after web browsers are no longer compatible with the code.
- User doesn't have to have anything but the program and documents to use in it. They will not have to install a MySQL database, or PHP, etc.
The Ideal Translation Helper Software
I ran into an awesome program the other day, The Hebrew Interlinear Bible. It lets you create your own translation of the bible by assigning the appropriate word to each hebrew word. When you make an association, every instance of that word in the entire old testament is "translated" as such. So, that was really cool and everything, but there are a few problems. As an individual issue, I seem to get a whole lot of I/O errors when doing simple things like scrolling through the pages or searching for a word. My husband (who runs linux) has no troubles at all, and neither do a lot of other people. But, even I/O errors aside, there are still some key features missing. The ability to export - at all. you can print the file, but there is no print dialog, it just sends the print command to your printer. I would like to have more than one translation going at a time, and the programs says you can, but I couldn't get it to work - mostly because of all the errors. I'd also like to add a new set of "strong's numbers", because, I feel that they are fundamentally flawed being based on the King James translation of the bible. This *is* possible, but then you loose the ability to use the real strong's numbers! The last actual problem with the program is that the creator hasn't released a new version since 2003, so I know none of these complaints will ever be taken care of. I didn't know I even wanted this program a few days ago, and now I can't do without it!
I looked online for a program that does a similar thing and found Paratext, but it was more like a gated community than a piece of software. I decided to make a list of what my ideal translation program would do...
Languages and Fonts:
Ability to translate texts from more than one language. Hebrew, Greek or any custom language the user could think up. Basically, you would name the language, pick a font and character mapping (unicode would be default but custom maps would be available for custom true type fonts) and then you would be able to assign new numbers and words to it. You would also be able to start out with a new blank language or base it off of an already existing one.
You would be able to apply a language or more than one language at the same time to a book and see what the differences are. An example would be Modern and Middle English. There are words that are the same, and there are words that have a completely different meaning today. This applies to all languages! not just English, and you should be able to use different sets of translation data for them.
Words:
One of the coolest things about the HIB was the built-in Hebrew word database. It knows which words are related to which other words, the only problem being that it was based on strong's numbering system which seriously needs updating. The creator of the program should not be expected to create a word and roots database for every language, so, there should be quick and easy ways for the user to do so. Everyone likes to use their own interpretation anyhow. The way this would work is by letting the user create base and root words, variations and assign "numbers". The numbers may only be for internal consistency for the actual program and the user wouldn't even have to see them. They would serve the same function as the base word data. Every word has a base and a root. Most of the time, they are the same word, but not always, and in the case of compounded words, they can have more than one of each. It would be nice to allow some way to include compound words into the system.
The first time the user opens a new language file and a book in that language, they can edit the options for any particular word. They would be able to denote a base word, if it is the base word, a root word, an etymology or notes section, if they like, about that word and create new translations of anticipated word combinations. For instance, if the first word they opened was Ran, they could set the root and base word as run, and then edit that base word and add runs, running, runner or any other word they liked as 'children' of the base of run. The, as they go through the book they are translating, and they come upon a new variation of run that they had forgotten, no big deal, they just type run in as the base word and it is automatically added in as a child of run. Why is this useful at all? Mostly for future reference, especially useful if you don't know a language well. Think of all the ways people have used the strong's reference numbers - now imagine they were words that meant something to you instead of numbers - you would be able to create word indexes, or create super-intelligent search algorithms. It would also be possible for someone to create a word relation index and then share it with another user but let them actually translate the word. This would be great for language students who are still struggling to know where words end and conjugations begin. This would also help anyone understand the original meaning of a text, since any translation is approximate - you could click on any word and see where it came from and view all the various translations possible for that word in various circumstances.
This base and root word function is nice, but the program would still 'work' without it. The functionality would just be limited, but someone could just manually enter the translation for each word individually and not worry about whether they are translating one instance of eretz as earth and when an and is added to it translate it as land.
The actual translation of the words would involve picking a translation for a specific word that will work for most circumstances, and then, when needed, choosing a separate translation for a single word instance. You could also denote if it is really the same word, but it needs to be translated a little differently in order to make sense in the language it is being translated in, or if it's actually a separate word that happens to be spelt alike. We can use our run example again. Run as in run a race could be denoted as having the base word of run1 and run as in I have a run in my pants could be denoted as having the base word of run2. In this case, they would share the same root word, because they really do mean the same thing in a twisted sort of way.
Note, I think it might be useful to have a tool specifically designed to create root/base relationship files for languages without having to open a text for that language.
Interlinear and Comparative:
One main function of this program would be to create interlinear texts. To one side you could have an accepted translation of the text, loaded in by yourself with markers added for chapters and an automatic parser for paragraphs, sentences or verses. These markers would have to be matched with your original source text file - and this would also be able to be done with a parser if possible, or a point and click system if necessary. The main section of the screen would be taken up with the main text to be edited. Underneath each word would be your own personal translation of the text, root words, base words, some other person's word for word translation of the same text and a place to create a more flowing version of the text with corrected word order, connecting words and grammar (or in some people's cases, theological manipulation). the order these appear, or if the appear at all would be up to each user, if you double click any of these rows, the edit screen pops up with whatever you selected in the focus. For instance, if you double click the root word spot, your cursor will be set in the root word edit box on the edit screen. You will still be able to click on any of these if they are empty (except the source text, obviously). Another, quicker, way to enter text would be to use the tab key - just click once in the appropriate row, a cursor would appear, and then type the word. Pressing tab would move you on to the next word. If you wanted to choose a separate meaning for the word, you would either double click the space or hit an F key, I think to automatically set it to the corresponding meaning.
The only thing that would work differently is the new 'flowing' version of the translation, each sentence/verse/paragraph should be visibly separate in the flowing version - this tool is for literal translations, after all. As above, these marks could be added all at once, or as you create the flowing part of the text.
You should also be able to change the source text - I think of instances where you have more then one version of the text you are translating, and you would need to choose the most likely version to trust in certain cases - these should be marked somehow when you do, however!
Output:
Output is a necessary step! You should be able to output the text as a PDF, plain text, xml, LaTex, html, odt, and others... this would be hard to do though .. I thin k that if the text always lives as xml, the export wouldn't be that bad.
It would be best if the output wasn't strictly for interlinear translations. You should be able to switch between pure interlinear, interlinear with a side translation, side by side comparisons, just the plain translation and so on. It could be / would be formatted in a two column format, with the mormon-style footnotes or commentary style footnotes, depending on the amount of footnote data involved. Just like in the mormon footnotes, these would be denoted in the footnote area by what type of footnote it is - for instance, a cross reference, a topical reference, a language note, commentary and so on. These types and their abbreviations would be set by the user.
This sort of works in with my idea for a lulu book generator, and if I could get that produced, I would certainly have this tool able to interface with it so you could go straight from translator to published book with only a few simple steps in between. But that, is really dreaming.
I looked online for a program that does a similar thing and found Paratext, but it was more like a gated community than a piece of software. I decided to make a list of what my ideal translation program would do...
Languages and Fonts:
Ability to translate texts from more than one language. Hebrew, Greek or any custom language the user could think up. Basically, you would name the language, pick a font and character mapping (unicode would be default but custom maps would be available for custom true type fonts) and then you would be able to assign new numbers and words to it. You would also be able to start out with a new blank language or base it off of an already existing one.
You would be able to apply a language or more than one language at the same time to a book and see what the differences are. An example would be Modern and Middle English. There are words that are the same, and there are words that have a completely different meaning today. This applies to all languages! not just English, and you should be able to use different sets of translation data for them.
Words:
One of the coolest things about the HIB was the built-in Hebrew word database. It knows which words are related to which other words, the only problem being that it was based on strong's numbering system which seriously needs updating. The creator of the program should not be expected to create a word and roots database for every language, so, there should be quick and easy ways for the user to do so. Everyone likes to use their own interpretation anyhow. The way this would work is by letting the user create base and root words, variations and assign "numbers". The numbers may only be for internal consistency for the actual program and the user wouldn't even have to see them. They would serve the same function as the base word data. Every word has a base and a root. Most of the time, they are the same word, but not always, and in the case of compounded words, they can have more than one of each. It would be nice to allow some way to include compound words into the system.
The first time the user opens a new language file and a book in that language, they can edit the options for any particular word. They would be able to denote a base word, if it is the base word, a root word, an etymology or notes section, if they like, about that word and create new translations of anticipated word combinations. For instance, if the first word they opened was Ran, they could set the root and base word as run, and then edit that base word and add runs, running, runner or any other word they liked as 'children' of the base of run. The, as they go through the book they are translating, and they come upon a new variation of run that they had forgotten, no big deal, they just type run in as the base word and it is automatically added in as a child of run. Why is this useful at all? Mostly for future reference, especially useful if you don't know a language well. Think of all the ways people have used the strong's reference numbers - now imagine they were words that meant something to you instead of numbers - you would be able to create word indexes, or create super-intelligent search algorithms. It would also be possible for someone to create a word relation index and then share it with another user but let them actually translate the word. This would be great for language students who are still struggling to know where words end and conjugations begin. This would also help anyone understand the original meaning of a text, since any translation is approximate - you could click on any word and see where it came from and view all the various translations possible for that word in various circumstances.
This base and root word function is nice, but the program would still 'work' without it. The functionality would just be limited, but someone could just manually enter the translation for each word individually and not worry about whether they are translating one instance of eretz as earth and when an and is added to it translate it as land.
The actual translation of the words would involve picking a translation for a specific word that will work for most circumstances, and then, when needed, choosing a separate translation for a single word instance. You could also denote if it is really the same word, but it needs to be translated a little differently in order to make sense in the language it is being translated in, or if it's actually a separate word that happens to be spelt alike. We can use our run example again. Run as in run a race could be denoted as having the base word of run1 and run as in I have a run in my pants could be denoted as having the base word of run2. In this case, they would share the same root word, because they really do mean the same thing in a twisted sort of way.
Note, I think it might be useful to have a tool specifically designed to create root/base relationship files for languages without having to open a text for that language.
Interlinear and Comparative:
One main function of this program would be to create interlinear texts. To one side you could have an accepted translation of the text, loaded in by yourself with markers added for chapters and an automatic parser for paragraphs, sentences or verses. These markers would have to be matched with your original source text file - and this would also be able to be done with a parser if possible, or a point and click system if necessary. The main section of the screen would be taken up with the main text to be edited. Underneath each word would be your own personal translation of the text, root words, base words, some other person's word for word translation of the same text and a place to create a more flowing version of the text with corrected word order, connecting words and grammar (or in some people's cases, theological manipulation). the order these appear, or if the appear at all would be up to each user, if you double click any of these rows, the edit screen pops up with whatever you selected in the focus. For instance, if you double click the root word spot, your cursor will be set in the root word edit box on the edit screen. You will still be able to click on any of these if they are empty (except the source text, obviously). Another, quicker, way to enter text would be to use the tab key - just click once in the appropriate row, a cursor would appear, and then type the word. Pressing tab would move you on to the next word. If you wanted to choose a separate meaning for the word, you would either double click the space or hit an F key, I think to automatically set it to the corresponding meaning.
The only thing that would work differently is the new 'flowing' version of the translation, each sentence/verse/paragraph should be visibly separate in the flowing version - this tool is for literal translations, after all. As above, these marks could be added all at once, or as you create the flowing part of the text.
You should also be able to change the source text - I think of instances where you have more then one version of the text you are translating, and you would need to choose the most likely version to trust in certain cases - these should be marked somehow when you do, however!
Output:
Output is a necessary step! You should be able to output the text as a PDF, plain text, xml, LaTex, html, odt, and others... this would be hard to do though .. I thin k that if the text always lives as xml, the export wouldn't be that bad.
It would be best if the output wasn't strictly for interlinear translations. You should be able to switch between pure interlinear, interlinear with a side translation, side by side comparisons, just the plain translation and so on. It could be / would be formatted in a two column format, with the mormon-style footnotes or commentary style footnotes, depending on the amount of footnote data involved. Just like in the mormon footnotes, these would be denoted in the footnote area by what type of footnote it is - for instance, a cross reference, a topical reference, a language note, commentary and so on. These types and their abbreviations would be set by the user.
This sort of works in with my idea for a lulu book generator, and if I could get that produced, I would certainly have this tool able to interface with it so you could go straight from translator to published book with only a few simple steps in between. But that, is really dreaming.
Subscribe to:
Posts (Atom)