Not signed in (Sign In)

Categories

Vanilla 1.1.4 is a product of Lussumo. More Information: Documentation, Community Support.

Help keep Vanilla free:
Welcome Guest!
Want to take part in these discussions? If you have an account, sign in now.
If you don't have an account, apply for one now.

Random: Online dictionary creator

Bottom of Page

51 to 72 of 72

  1. <
  2. 1
  3. 2
  4. >
    • CommentAuthorMinisweeper
    • CommentTimeAug 15th 2005 edited
     # 51
    haha lech, hacktastic probably sums up my abilities quite well too.
    The way i write the file is the same way mark writes the extension file, which i assume is similar if not identical to the way he writes the settings file.
    N.B Martis effort is considerably better and more sensible than mine - out of interest marti, why do you choose to blank the file by writing <<<EOF to it as opposed to just opening and truncating it using the 'wb' flags as opposed to the 'w' flag in fopen()?
    •  
      CommentAuthorlech
    • CommentTimeAug 15th 2005
     # 52
    the <<<EOF is just a method of writing large text blocks, he's just keeping the header comments in-tact.
  3.  # 53
    oh, ok, i assumed it was a way of blanking the file. My bad.
    •  
      CommentAuthorlech
    • CommentTimeAug 15th 2005
     # 54
    Mark, while this might seem like a semi-insane idea, why not switch the language dictionaries over to raw but simple xml? The reason I suggest this is probably for accesibility purposes when updating or writing new up-to-date language files. The end-user could simply load a recent copy straight off of the server or say a hosted mirror, and write it back to their installation as needed. Future thoughts.
    •  
      CommentAuthorlech
    • CommentTimeAug 15th 2005
     # 55
    http://www.secondagenda.com/vanilla/english.xml

    took the liberty of sorting it out the best I could based on comments. Mark, I bet you've either extended or have rewritten this, but either way, it's just a practice file.
    •  
      CommentAuthorMark
    • CommentTimeAug 15th 2005
     # 56
    I won't be switching it to xml. It's already a HUGE array that probably is pretty heavy on php being that it is loaded on every page. I'm not adding the extra overhead of pulling it from an xml file and parsing it out.

    Also, just because it's in xml format doesn't mean that it's any easier to save it to a file. Why not just save it as php code in a text file the way I've done with the appg/settings.php file? It's basically doing the same thing, but not wasting any processor time on parsing xml.
  7.  # 57
    it does look prettier in xml though....

    So do you want someone to carry on working on this mark or do you want to implement your idea? (Or anyone else, i know i couldnt do it)
    •  
      CommentAuthorMark
    • CommentTimeAug 16th 2005
     # 58
    Like I said, I won't be switching the dictionary to xml.
    •  
      CommentAuthorMarti
    • CommentTimeAug 16th 2005 edited
     # 59
    I already brought this up in another discussion, but what about GNU gettext? I don't know much about it, but I bet it's faster than including a php language file because the language files it uses are in binary. It can also handle different types of plural forms.

    GNU's manual for gettext is quite lengthy, but there's plenty of other material about it that should b e enough to see how it is used. Here's one article about it: http://mel.melaxis.com/devblog/2005/08/06/localizing-php-web-sites-using-gettext/
  10.  # 60
    lol mark, i wasnt implying you should, i was just being silly.
    •  
      CommentAuthorlech
    • CommentTimeAug 16th 2005 edited
     # 61
    Mark, I wasn't implying that it should be in xml the entire time. Simply saying that before it gets written out to proper associative arrays like it is currently, it's stored as xml, then comes along the dictionary editor, pulling the default values from the xml file, and the dictionary writer stores the associative arrays to the final output file like they are currently.

    This would probably be useful in the whole ping for update routine, instead of pulling php or phps files from the master server, it's simply loading up xml. I wouldn't want vanilla parsing through a possibly larger xml file either. You understand that, right? It's just a little suggestion which could go a long way later.
    •  
      CommentAuthorMark
    • CommentTimeAug 16th 2005
     # 62
    ahhhhhh - I see what you're saying...
    •  
      CommentAuthorlech
    • CommentTimeAug 16th 2005
     # 63
    :D it's pure genius!
    •  
      CommentAuthorlech
    • CommentTimeAug 16th 2005
     # 64
    Mark, since I have no expertise in this, is there a way to call the XML lib into play via extension? or is that simply reserved for the functionality of all the AJAX used onboard?
    •  
      CommentAuthornathan
    • CommentTimeAug 16th 2005
     # 65
    >> ahhhhhh - I see what you're saying...

    It clicked. YAY!
    •  
      CommentAuthorMark
    • CommentTimeAug 16th 2005
     # 66
    Actually, that xml parser is a piece of garbage I coded for the filebrowser. It's fast, but completely inflexible. I'll probably be trashing it for the next rev of the filebrowser.
    •  
      CommentAuthorlech
    • CommentTimeAug 16th 2005
     # 67
    ahh, gotcha, I took a quick look at it but couldn't make heads or tails of whether it was worth it or not. I'll see if I can come up with my own class or library overnight to test this little idea of mine sprinkled with mini and marti's bits of code.
  18.  # 68
    suggestion: take martis, it makes much more sense. I must admit if people wanted me to carry this project on i'd use his code as the base (with his permission obviously)
    i still dont quite get the xml thing, but yay!
    •  
      CommentAuthorlech
    • CommentTimeAug 16th 2005 edited
     # 69
    Mini, there's some stuff in both of the source files you guys have provided which proves useful in how you're reading and saving the files, I'm simply using them as reference for now. But by all means though, don't leave this up to me, continue to come up with your own twists.

    The xml thing is simply an idea I'm right now toying with as a static source for all dictionaries. Meaning you can only read from it, but not over-write it. Also it serves to aid if mark decides to really go through with performing remote extension updates and the like. This way, if say, the master dictionary file for some reason get's screwed up, you can simply pull it into the dictionary creator, and output a brand new one.

    master dictionary.xml@lussumo.com -> Dictionary Editor on your server -> Write out new dictionary file

    This could also possibly serve as a cross reference point if say, you have customized your dictionary file and upon update, really don't want to go through once again and make the same changes. I suppose I could also output a custom_languagename.xml to store all those changes in addition to spitting out the language file with it's proper associative array. So at update time, it could do a quick one-time sweep through existing keys, look for changes you've made and change them again to what they were instead of using new ones.
    •  
      CommentAuthorlech
    • CommentTimeAug 16th 2005
     # 70
    mark, i've also noticed two duplicate entries in the english.php language file.

    // Added July 17, 2005
    $Context->Dictionary["ErrPermissionAddComments"] = "You do not have permission to add comments to discussions.";
    $Context->Dictionary["ErrPermissionStartDiscussions"] = "You do not have permission to start discussions.";
  21.  # 71
    how is that a duplicate?
    And i'm still not 100% but i get the basic xml idea. If i was give it the ability to do revisions, what would be the best way to do this? Add a comment after each line with the name+time (and previous value?)?
    •  
      CommentAuthorlech
    • CommentTimeAug 17th 2005
     # 72
    mini, do a search in the default /languages/english.php for those 2 lines I previously posted and you'll see 2 instances of them.

    I've got the groundwork laid down for the language editor/writer extension and it's functional as far as a simple extension goes. I just need to populate it with some of the functionality you and marti have laid down up to this point. I just now need to keep some security in mind while writing out the functionality of this extension file.

    here's The xml idea in detail since you still don't get it mini :)

    In brief, storing the current associative array of values found in the [languagenamehere].php file into a master xml file, IE english.xml. This would be a totally seperate and static XML file. This is where the language editor extension comes fully into play. Instead of reading the current language php file, it would pull everything from the XML file, either locally or grab a fresh set of entries off of the lussumo server. Then you could either save it as is to your server, or edit it up and save new or over an existing language file without the need to go in by hand and upload stuff.

    I suppose the same could be done for extensions themselves later on as well as for updating other modules. deliver it all as XML, and write it out as php. But right now I'm only starting with single language files. I'll see if I can get some XML functionality in there to start letting you at least back up the file as XML to start, that should be fairly simple. Reading from XML is another story.

51 to 72 of 72

  1. <
  2. 1
  3. 2
  4. >
Add your comments
    Username Password
  • Format comments as
 
Back to Discussions Top of Page