Help Wanted: OHM content transfer

[Saga Musix]

Hello all,
cubaxd and me are finally working on setting up the new English OpenMPT Wiki.
The wiki will be based on the OHM by Harbinger and will eventually serve as a basis for generating a quick start guide that can be included with OpenMPT.
Luckily, thanks to Harbinger, all the content is already there - it's just in the wrong place. Now, the plan is to
- proof-read existing texts (there are still many minor and not-so-minor wrong facts in the OHM) and
- transfer them to the wiki afterwards.
- All screenshots should also be re-done for a more consistent look and decreased file size.

The wiki structure will be set up by us first, then converting / transferring articles can be started. For the latter, we need your help. I am looking for people that would be willing to spend some time proof-reading texts from the OHM and then copy them to the wiki. Requirements are:
- Some experience with OpenMPT. If you feel very confident with you knowledge about a certain part of OpenMPT, you are more than welcome than proof-reading / uploading texts from that section. Of course you don't have to be an expert in everything (who is that, anyway?), so if you feel unsure about an article you are copying, you can simply ask here.
- Basic experience with MediaWiki. MediaWiki uses a rather uncommon markup system that doesn't look like HTML or BB Codes. MediaWiki doesn't come with a WYSIWYG editor, but provides some buttons for inserting MediaWiki markup. It's really simple, but if you have never worked with MediaWiki software (f.e. on Wikipedia), you should have a look at their help sites.

This may sound like some big requirements, but they are really basic. The more people help, the less work it is for everyone of us. I'm looking forward to your responses.

[Rakib]

Im in!
Would be glad to help.

[jmkz]

Also I

[kit beats]

Me Mio = IN

[Saga Musix]

Thanks for your interest. The wiki is in progress of being set up, and some articles have already been copied over for testing the look and layout of the pages. While doing so, I thought I should probably set up a preliminary style guide that should be taken care of when transfering articles:

- Apostrophes: "VST's", and even more so "VST´s" is not a correct english plural. Plurals go without an apostrophe (or even accent as in the latter example), so please remove those when you spot them.
- Prefer writing out words over informal style, f.e. "you will" instead of "you'll", or "cannot" over "can't". It simply looks better in such a document.
- Replace passages written in CAPS by bold print or italic print where it makes sense.
- Always use "MIDI", not "Midi".
- Similarly, "ModPlug" should be preferred over "Modplug".

[Harbinger]

Hell, even i'll help wherever i can!
 
Keep in mind folks, i'm about 90% done with the 1.19 CHM version and i do have a lot of updated OHM subdocs ready to upload. It'd been better if Jojo had sent me a PM requesting the latest version of the OHM subdocs, but we'll forgive him this time !
 
I intend to transfer all the non-Reference documents to the CHM Helpfile, but keep the Reference section as a separate PDF. If MPT 1.20 is less than a few months off from release, i'll hold off and update what i have with the new features. Eventually this will hopefully spawn a single HTML file for those who aren't or don't want to be online when they're tracking, but like the navigation features available in HTML. Of course, none of this has any bearing on the OpenMPT Wiki assembly.
 
One last thing:
I encourage you if you want to know the correct pluralization of ENGLISH acronyms, you read this from the Wikipedia page:

Plurals of symbols and initialisms
Individual letters and abbreviations whose plural would be ambiguous if only an -s were added are pluralized by adding -'s.
  mind your p's and q's
  A.A.'s and B.A.'s
  the note had three PS's 
Opinion is divided on whether to extend this use of the apostrophe to related but nonambiguous cases, such as the plurals of numerals (e.g., 1990's vs. 1990s) and words used as terms (e.g., "his writing uses a lot of but's" vs. "his writing uses a lot of buts"). Some writers favor the use of the apostrophe as consistent with its application in ambiguous cases; others say it confuses the plural with the possessive -'s and should be avoided whenever possible in pluralization, a view with which The Chicago Manual of Style concurs.
...
Acronyms are initialisms that are used and pronounced as if they were words. For example, we have AMTRAK, HAL, LEM, NASA, and NATO. These contrast with the different variety that are read aloud one letter at a time: {C.I.A., C.S.M., D.O.D., E.U., G.C.M., G.P.S., I.B.M., N.A.C.A., N.S.A., R.C.A., R.P.M., S.S.T., T.W.A., U.S.S.R., W.P.A., etc.}
The most consistent approach for pluralizing pronounceable acronyms is to simply add a lowercase "s" as its suffix. This works well even for acronyms ending with an s, such as with CASs (pronounced "kazzes"), while still making it possible to use the possessive form ("'s") for the acronyms without confusion. The old, old style of pluralizing single letters with "'s" was naturally extended to acronyms when they were all commonly written with periods. This form is still preferred by some people for all initialisms and thus "'s" as a suffix is often seen in informal usage.

"VSTs" is universally accepted, but according to this article, my education was right, acronyms are to be pluralized with 's to eliminate ambiguity. "VSTis" could be construed as a typo of "VST is" or "overread" as "VSTs" for those who read quickly. Since VSTi is the universal term for a VST-based instrument, then the only question is whether to PROPERLY pluralize it or pluralize it to the whim of one or two.
If an argument is to be made that the pluralization of VSTi may be confused with the possessive form of VSTi, then i defer to the context of the sentence in which "VSTi's" is found.
 
If there is still disagreement after this, perhaps we should take a vote by the members of the forum.
 
Other than that, i'm totally in agreement with Jojo's standardization guidelines.

[Saga Musix]

That article also says:

The most consistent approach for pluralizing pronounceable acronyms is to simply add a lowercase "s" as its suffix.

"VSTis" is pretty pronounceable, so there are arguments for both cases. We could simply go for "VST instruments", there is no doubt in how to pluralize that. It would also make distinction between effects and instruments easier, because the difference would be more than just a single letter.

I intend to transfer all the non-Reference documents to the CHM Helpfile

I hope you have not spent too much time figuring out how to create CHM files, because I can just use the wiki to create DocBook documentation (next to PDF/ODF export), which then can be compiled into CHM files.

[Harbinger]

That article also says:

The most consistent approach for pluralizing pronounceable acronyms is to simply add a lowercase "s" as its suffix.

"VSTis" is pretty pronounceable, so there are arguments for both cases. We could simply go for "VST instruments", there is no doubt in how to pluralize that. It would also make distinction between effects and instruments easier, because the difference would be more than just a single letter.

No, "VSTi" is not pronounceable, unless you're pronouncing it as "vist-ee" or the like. I've always read it and prounced the term "V-S-T-I" one letter at a time.

I believe the first sentence of a guidelines paragraph should be the one that carries the most weight, unless it can be shown that exceptions can be found...

Perhaps we should start a vote...

I intend to transfer all the non-Reference documents to the CHM Helpfile

I hope you have not spent too much time figuring out how to create CHM files, because I can just use the wiki to create DocBook documentation (next to PDF/ODF export), which then can be compiled into CHM files.

Uh, yeah, as a matter of fact i have. Like i said, "i'm about 90% done with the 1.19 CHM version ". It will be done a lot sooner than you can export one from the Wikipedia documentation. Plus, i have added a few more things which are not present in the current OHM, not just updated info.

Concerning any progress on the help manual front, since i have been the one to do the most assembly of something everyone can use to shallow out the learning curve, i would appreciate PMs concerning anyone's intentions of help files that will be made public. I have a lot more than what you see in the OHM or what's been uploaded at sourceforge, such as notes, images, etc.
YOU can save yourself alot of work.

[Saga Musix]

Sorry, I misunderstood the word "pronounceable". Anyway, I'm still with "others say it confuses the plural with the possessive -'s and should be avoided whenever possible". If somone else has an opinion, state it here.

It would be helpful if you could at least provide an updated TOC if the new documentation is not ready yet - currently we have set up a slightly altered TOC with page references, which would need to be updated if any page numbers have changed.

[Harbinger]

I have a myriad of other projects going, but i will try to fit it into my schedule. I guess i can put off trying to complete and touch-up the CHM, and focus on compiling all the changed documents and images now that other versions are to be made available. Give me a week. 

[Saga Musix]

Current wiki main page with reordered TOC:

[Harbinger]

Pretty snazzy!

I especially like that the ONLINE help is called the OpenMPT Wiki page. I was always concerned that new users would misunderstand the OHM as the online version rather than OFFLINE.

Now if we can get these pages written up and some of the new sensible FRs coded, we'll be the number one tracker out there!

[Harbinger]

It would be helpful if you could at least provide an updated TOC if the new documentation is not ready yet - currently we have set up a slightly altered TOC with page references, which would need to be updated if any page numbers have changed.

After reviewing my copy of the docs, i realized i only made a couple of small changes to the current OHM source docs, mostly corrections mentioned by Jojo, including the use of %APPDATA%. Shortly after 1.19.01 was uploaded, i went about starting the CHM version (Windows Helpfile), and imported all the OHM docs into that project. While i did make corrections and updates, i made them to the CHM not the OHM. Therefore the source docs do not have all the updates and edits needed for the Wiki page authors.

The upshot of all this is that i can upload nothing of real import to the effort; that is, you'll have to use the OHM source docs that are currently at sourceforge. I will update the source docs AFTER the CHM is complete, and i "retrodate" (as opposed to update) my source docs before uploading to sourceforge. IOW, i will continue making edits to the CHM, then when i'm done, go back and edit the OHM based on my work in the CHM. Capiche?

This means of course it will take more than a week, more like a few months, unless i can get my schedule cleared and interest piqued. Do what you can with what is there at sourceforge...

[Saga Musix]

OK. I guess retrofitting changes into the Wiki shouldn't be much of a problem, just a lot of work probably. Though on the other hand, as advised in the first post, people should proof-read texts before submitting them anyway, so there is a chance that at least some corrections will make it on the wiki before you get to release an updated version anyway.

[Exhale]

I can help with the pictures / design if you need any. looking at the ohm, I think so, I'm a graphic designer, and I often come on this webpage so send me a message.