Not using the most up to date DOCTYPE declaration for your markup means not being able to use the entities which might be suggested below, when checking for applicable entities.

People who spent time on translating your document should be given credit appropriately. To do this, you need to specify two special comments in your markup:

<!-- TRANS:ROLES_OF_TRANSLATORS -->
This special comment must appear exactly once in your markup; you should put it at the end of your <authorgroup> element.

<!-- TRANS:CREDIT_FOR_TRANSLATORS -->
There must only be one DocBook file in the directory which has this marker. It needs to be placed at the end of your document, right before the &underFDL; entity.

Not using the most up to date DOCTYPE declaration for your markup means not being able to use the entities which might be suggested below, when checking for applicable entities.

People who spent time on translating your document should be given credit appropriately. To do this, you need to specify two special comments in your markup:

<!-- TRANS:ROLES_OF_TRANSLATORS -->
This special comment must appear exactly once in your markup; you should put it at the end of your <authorgroup> element.

<!-- TRANS:CREDIT_FOR_TRANSLATORS -->
There must only be one DocBook file in the directory which has this marker. It needs to be placed at the end of your document, right before the &underFDL; entity.

• In line 16: Prefer 'email' over 'e-mail'.

  ..<para>If it does, you can now report the problem to the developer's list, and mention that you have anonymous file that reproduces the problem. When requested, send the anonymous file via private e-mail to whichever developer requests it.</para>..

For the sake of consistency (and proper spelling), there is a centralized list of common phrases and how they should be spelt in KDE manuals. This covers cases such as "file system" vs. "filesystem" or "Spell-check" vs. "Spellcheck". It's a matter of professional appearance, and you should really try to make your spelling consistent with that of the other KDE documents.

Note:It is not guaranteed that the document is still valid after applying these suggestions! If you happen to see a suggestion which would break the document, please send Frerich Raabe a mail about it.

• Entity could be used in line 9:

  -<para>The .KMY file is a gzipped XML file.  If you wish to learn about the structure of the file, you can gunzip it and load it in your favorite text editor.</para>
  +<para>The .KMY file is a gzipped &XML; file.  If you wish to learn about the structure of the file, you can gunzip it and load it in your favorite text editor.</para>
  

• Entity could be used in line 14:

  -	<para>To save a copy of your file in this way, open the File menu from the application menu bar, and choose &quot;Save as...&quot;.  For the file type, choose &quot;Anonymous (.ANON.XML)&quot;.  This will save off a copy of your data in anoymous form.</para>
  +	<para>To save a copy of your file in this way, open the File menu from the application menu bar, and choose &quot;Save as...&quot;.  For the file type, choose &quot;Anonymous (.ANON.&XML;)&quot;.  This will save off a copy of your data in anoymous form.</para>
  

There are a lot of entities available to authors of KDE manuals which make it easy to keep the spelling of applications and abbreviations consistent. Using them makes sure that application names are capitalized and marked up correctly, licensed terms get proper 'trademark' and 'copyright' signs, keys which are labelled differently in different countries (such as the 'Ctrl' key which is labelled 'Strg' on german keyboards) get automatically translated and more. To make a long story short - you don't lose anything when using entities as much as possible, but you gain a lot.

Not using the most up to date DOCTYPE declaration for your markup means not being able to use the entities which might be suggested below, when checking for applicable entities.

• Found empty <para> element in line 3.

Elements without any content make it impossible to translate the DocBook file into other languages; in particular, the xml2po program which is used by the KDE translation framework will break. You need to remove those elements, or fill them with some dummy content like "FILL ME WITH CONTENT" or such.

People who spent time on translating your document should be given credit appropriately. To do this, you need to specify two special comments in your markup:

<!-- TRANS:ROLES_OF_TRANSLATORS -->
This special comment must appear exactly once in your markup; you should put it at the end of your <authorgroup> element.

<!-- TRANS:CREDIT_FOR_TRANSLATORS -->
There must only be one DocBook file in the directory which has this marker. It needs to be placed at the end of your document, right before the &underFDL; entity.

Not using the most up to date DOCTYPE declaration for your markup means not being able to use the entities which might be suggested below, when checking for applicable entities.

People who spent time on translating your document should be given credit appropriately. To do this, you need to specify two special comments in your markup:

<!-- TRANS:ROLES_OF_TRANSLATORS -->
This special comment must appear exactly once in your markup; you should put it at the end of your <authorgroup> element.

<!-- TRANS:CREDIT_FOR_TRANSLATORS -->
There must only be one DocBook file in the directory which has this marker. It needs to be placed at the end of your document, right before the &underFDL; entity.

• In line 73: Prefer '' over '&kappname;'. (Use the entity for this application instead)

  ..As with the personal information dialog, this data is not currently used by &kappname; but will be required by future releases for certain features. Once you have entered the name click on <guibutton>OK</guibutton> to select the institution or click on <guibutton>Cancel</guibutton> to not use an institution for this account. To select an existing institution simply click on the institution drop down list...

• In line 143: Prefer '' over '&kappname;'. (Use the entity for this application instead)

  ..To make this account your primary account check the tickbox labelled <guilabel>Preferred account</guilabel> This account will then be used by default within &kappname; for your convenience...

• In line 205: Prefer '' over '&kappname;'. (Use the entity for this application instead)

  ..If this is not a Credit Card account then all required information has been gathered and you can add the account to &kappname; by clicking on the <guibutton>Finish</guibutton> button. If you do not wish to add the account click on <guibutton>Cancel</guibutton>...

• In line 244: Prefer 'drop down box' over 'drop down list'.

  ..To open an account in the Ledgers view you can either click on the link to the account from the Home view, or click on the <guiicon><inlinemediaobject><imageobject><imagedata fileref="ledgers_view.png"/></imageobject></inlinemediaobject>Ledgers</guiicon> icon in the view selector and select the account in the drop down list at the top of the view...

For the sake of consistency (and proper spelling), there is a centralized list of common phrases and how they should be spelt in KDE manuals. This covers cases such as "file system" vs. "filesystem" or "Spell-check" vs. "Spellcheck". It's a matter of professional appearance, and you should really try to make your spelling consistent with that of the other KDE documents.

Not using the most up to date DOCTYPE declaration for your markup means not being able to use the entities which might be suggested below, when checking for applicable entities.

People who spent time on translating your document should be given credit appropriately. To do this, you need to specify two special comments in your markup:

<!-- TRANS:ROLES_OF_TRANSLATORS -->
This special comment must appear exactly once in your markup; you should put it at the end of your <authorgroup> element.

<!-- TRANS:CREDIT_FOR_TRANSLATORS -->
There must only be one DocBook file in the directory which has this marker. It needs to be placed at the end of your document, right before the &underFDL; entity.

• In line 43: Prefer '&ie;' over 'ie.'. (Use the entity!)

  ..The schedule consists of two main parts; the scheduling data and the transaction itself. The scheduling data records the occurrence of the schedule, ie. when the transaction is to be entered into the ledger and how. The transaction data records normal transaction information and will be entered in to the ledger as-is...

• In line 157: Prefer '' over '&kappname;'. (Use the entity for this application instead)

  ..<title>Letting &kappname; enter the transaction into the register</title>..

• In line 159: Prefer '' over '&kappname;'. (Use the entity for this application instead)

  ..To let &kappname; enter the transaction for you when needed make sure that the check box labelled <guilabel>Enter this into the ledger automatically</guilabel> is checked otherwise when the transaction is due to be entered, &kappname; will open a dialog box asking you to confirm that you want it to be entered. This behavior is configurable and more information can be found in the Settings section...

• In line 164: Prefer '' over '&kappname;'. (Use the entity for this application instead)

  ..<title>Letting &kappname; know when the schedule will finish</title>..

• In line 323: Prefer '' over '&kappname;'. (Use the entity for this application instead)

  ..<title>Letting &kappname; enter the schedule(s) for you</title>..

• In line 325: Prefer '' over '&kappname;'. (Use the entity for this application instead)

  ..Alternatively &kappname; can check which schedules are due upon startup and enter them for you if the appropriate option was checked when setting up the schedule...

• In line 329: Prefer '' over '&kappname;'. (Use the entity for this application instead)

  ..If the option was not checked then &kappname; will open the previously mentioned dialog and you can follow the steps mentioned there. &kappname; will also open the dialog if the amount is an estimate so you can enter the real amount...

• In line 333: Prefer '' over '&kappname;'. (Use the entity for this application instead)

  ..You can also opt to have &kappname; not check the schedules on startup by deselecting the option in the Settings dialog and any overdue schedules or schedules due 'today' will be shown in the Home view for you to enter manually...

For the sake of consistency (and proper spelling), there is a centralized list of common phrases and how they should be spelt in KDE manuals. This covers cases such as "file system" vs. "filesystem" or "Spell-check" vs. "Spellcheck". It's a matter of professional appearance, and you should really try to make your spelling consistent with that of the other KDE documents.

Not using the most up to date DOCTYPE declaration for your markup means not being able to use the entities which might be suggested below, when checking for applicable entities.

People who spent time on translating your document should be given credit appropriately. To do this, you need to specify two special comments in your markup:

<!-- TRANS:ROLES_OF_TRANSLATORS -->
This special comment must appear exactly once in your markup; you should put it at the end of your <authorgroup> element.

<!-- TRANS:CREDIT_FOR_TRANSLATORS -->
There must only be one DocBook file in the directory which has this marker. It needs to be placed at the end of your document, right before the &underFDL; entity.

Note:It is not guaranteed that the document is still valid after applying these suggestions! If you happen to see a suggestion which would break the document, please send Frerich Raabe a mail about it.

• Entity could be used in line 83:

  -regular expresssion.  For details on how to craft a regular expression, visit the Qt documentation at doc.trolltech.com, and look for the QRegExp class.
  +regular expresssion.  For details on how to craft a regular expression, visit the &Qt; documentation at doc.trolltech.com, and look for the QRegExp class.
  

There are a lot of entities available to authors of KDE manuals which make it easy to keep the spelling of applications and abbreviations consistent. Using them makes sure that application names are capitalized and marked up correctly, licensed terms get proper 'trademark' and 'copyright' signs, keys which are labelled differently in different countries (such as the 'Ctrl' key which is labelled 'Strg' on german keyboards) get automatically translated and more. To make a long story short - you don't lose anything when using entities as much as possible, but you gain a lot.

Not using the most up to date DOCTYPE declaration for your markup means not being able to use the entities which might be suggested below, when checking for applicable entities.

People who spent time on translating your document should be given credit appropriately. To do this, you need to specify two special comments in your markup:

<!-- TRANS:ROLES_OF_TRANSLATORS -->
This special comment must appear exactly once in your markup; you should put it at the end of your <authorgroup> element.

<!-- TRANS:CREDIT_FOR_TRANSLATORS -->
There must only be one DocBook file in the directory which has this marker. It needs to be placed at the end of your document, right before the &underFDL; entity.

Not using the most up to date DOCTYPE declaration for your markup means not being able to use the entities which might be suggested below, when checking for applicable entities.

• Found empty <para> element in line 3.

Elements without any content make it impossible to translate the DocBook file into other languages; in particular, the xml2po program which is used by the KDE translation framework will break. You need to remove those elements, or fill them with some dummy content like "FILL ME WITH CONTENT" or such.

People who spent time on translating your document should be given credit appropriately. To do this, you need to specify two special comments in your markup:

<!-- TRANS:ROLES_OF_TRANSLATORS -->
This special comment must appear exactly once in your markup; you should put it at the end of your <authorgroup> element.

<!-- TRANS:CREDIT_FOR_TRANSLATORS -->
There must only be one DocBook file in the directory which has this marker. It needs to be placed at the end of your document, right before the &underFDL; entity.

Not using the most up to date DOCTYPE declaration for your markup means not being able to use the entities which might be suggested below, when checking for applicable entities.

People who spent time on translating your document should be given credit appropriately. To do this, you need to specify two special comments in your markup:

<!-- TRANS:ROLES_OF_TRANSLATORS -->
This special comment must appear exactly once in your markup; you should put it at the end of your <authorgroup> element.

<!-- TRANS:CREDIT_FOR_TRANSLATORS -->
There must only be one DocBook file in the directory which has this marker. It needs to be placed at the end of your document, right before the &underFDL; entity.

• In line 8: Prefer '' over '&kappname;'. (Use the entity for this application instead)

  ..Put simply, &kappname; is a personal finances manager for KDE. It enables users of open source operating systems to keep careful track of their personal finances by providing a broad array of financial features and tools...

• In line 23: Prefer '' over '&kappname;'. (Use the entity for this application instead)

  ..Based on tried and tested double entry accounting principles &kappname; ensures that your finances are kept in correct order...

• In line 30: Prefer '' over '&kappname;'. (Use the entity for this application instead)

  ..<title>What &kappname; is not</title>..

• In line 33: Prefer '' over '&kappname;'. (Use the entity for this application instead)

  ..As a personal finances manager, &kappname; is not intended to scale to the needs of an average business. It would be possible to create client / supplier / document features through plugins...

• In line 37: Prefer '' over '&kappname;'. (Use the entity for this application instead)

  ..&kappname; is not simply a clone of the commercially-available personal finance programs. Although many of the features present in &kappname; can be found in other similar applications, &kappname; strives to present an individual and unique view of your finances...

For the sake of consistency (and proper spelling), there is a centralized list of common phrases and how they should be spelt in KDE manuals. This covers cases such as "file system" vs. "filesystem" or "Spell-check" vs. "Spellcheck". It's a matter of professional appearance, and you should really try to make your spelling consistent with that of the other KDE documents.

Note:It is not guaranteed that the document is still valid after applying these suggestions! If you happen to see a suggestion which would break the document, please send Frerich Raabe a mail about it.

• Entity could be used in line 8:

  -Put simply, &kappname; is a personal finances manager for KDE.  It enables users of open source operating systems to keep careful track of their personal finances by providing a broad array of financial features and tools.
  +Put simply, &kappname; is a personal finances manager for &kde;.  It enables users of open source operating systems to keep careful track of their personal finances by providing a broad array of financial features and tools.
  

There are a lot of entities available to authors of KDE manuals which make it easy to keep the spelling of applications and abbreviations consistent. Using them makes sure that application names are capitalized and marked up correctly, licensed terms get proper 'trademark' and 'copyright' signs, keys which are labelled differently in different countries (such as the 'Ctrl' key which is labelled 'Strg' on german keyboards) get automatically translated and more. To make a long story short - you don't lose anything when using entities as much as possible, but you gain a lot.

Not using the most up to date DOCTYPE declaration for your markup means not being able to use the entities which might be suggested below, when checking for applicable entities.

People who spent time on translating your document should be given credit appropriately. To do this, you need to specify two special comments in your markup:

<!-- TRANS:ROLES_OF_TRANSLATORS -->
This special comment must appear exactly once in your markup; you should put it at the end of your <authorgroup> element.

<!-- TRANS:CREDIT_FOR_TRANSLATORS -->
There must only be one DocBook file in the directory which has this marker. It needs to be placed at the end of your document, right before the &underFDL; entity.

Not using the most up to date DOCTYPE declaration for your markup means not being able to use the entities which might be suggested below, when checking for applicable entities.

• Found empty <para> element in line 3.

Elements without any content make it impossible to translate the DocBook file into other languages; in particular, the xml2po program which is used by the KDE translation framework will break. You need to remove those elements, or fill them with some dummy content like "FILL ME WITH CONTENT" or such.

People who spent time on translating your document should be given credit appropriately. To do this, you need to specify two special comments in your markup:

<!-- TRANS:ROLES_OF_TRANSLATORS -->
This special comment must appear exactly once in your markup; you should put it at the end of your <authorgroup> element.

<!-- TRANS:CREDIT_FOR_TRANSLATORS -->
There must only be one DocBook file in the directory which has this marker. It needs to be placed at the end of your document, right before the &underFDL; entity.

Not using the most up to date DOCTYPE declaration for your markup means not being able to use the entities which might be suggested below, when checking for applicable entities.

People who spent time on translating your document should be given credit appropriately. To do this, you need to specify two special comments in your markup:

<!-- TRANS:ROLES_OF_TRANSLATORS -->
This special comment must appear exactly once in your markup; you should put it at the end of your <authorgroup> element.

<!-- TRANS:CREDIT_FOR_TRANSLATORS -->
There must only be one DocBook file in the directory which has this marker. It needs to be placed at the end of your document, right before the &underFDL; entity.

• In line 25: Prefer '' over '&kappname;'. (Use the entity for this application instead)

  ..A loan is an agreement where a borrower receives money from a lender and agrees to return the money at some future date. &kappname; allows you to track loans with which you borrow money (you are the borrower) or lend money (you are the lender). In personal finance, it always seems that a person always borrows more than he or she lends. This means that you will generally be the borrower and a mortgage company or auto loan company will generally be the lender. In the circumstance where you loan money to a family member or a friend, you can use &kappname; to track this loan as well...

For the sake of consistency (and proper spelling), there is a centralized list of common phrases and how they should be spelt in KDE manuals. This covers cases such as "file system" vs. "filesystem" or "Spell-check" vs. "Spellcheck". It's a matter of professional appearance, and you should really try to make your spelling consistent with that of the other KDE documents.

Not using the most up to date DOCTYPE declaration for your markup means not being able to use the entities which might be suggested below, when checking for applicable entities.

• Found empty <para> element in line 3.

Elements without any content make it impossible to translate the DocBook file into other languages; in particular, the xml2po program which is used by the KDE translation framework will break. You need to remove those elements, or fill them with some dummy content like "FILL ME WITH CONTENT" or such.

People who spent time on translating your document should be given credit appropriately. To do this, you need to specify two special comments in your markup:

<!-- TRANS:ROLES_OF_TRANSLATORS -->
This special comment must appear exactly once in your markup; you should put it at the end of your <authorgroup> element.

<!-- TRANS:CREDIT_FOR_TRANSLATORS -->
There must only be one DocBook file in the directory which has this marker. It needs to be placed at the end of your document, right before the &underFDL; entity.

Not using the most up to date DOCTYPE declaration for your markup means not being able to use the entities which might be suggested below, when checking for applicable entities.

People who spent time on translating your document should be given credit appropriately. To do this, you need to specify two special comments in your markup:

<!-- TRANS:ROLES_OF_TRANSLATORS -->
This special comment must appear exactly once in your markup; you should put it at the end of your <authorgroup> element.

<!-- TRANS:CREDIT_FOR_TRANSLATORS -->
There must only be one DocBook file in the directory which has this marker. It needs to be placed at the end of your document, right before the &underFDL; entity.

• In line 27: Prefer 'drop down box' over 'drop down list'.

  ..To reconcile an account click on the <guiicon><inlinemediaobject><imageobject><imagedata fileref="reconcile.png"/></imageobject></inlinemediaobject> Reconcile Ledgers</guiicon> icon in the account selector, choose your account from the drop down list and then click on the <guibutton>Reconcile</guibutton> button...

• In line 94: Prefer '&eg;' over 'e.g.'. (Use the entity!)

  ..The interest field is for interest you gained. If you have to pay interest for e.g. a credit card account, this has to be entered as charge...

For the sake of consistency (and proper spelling), there is a centralized list of common phrases and how they should be spelt in KDE manuals. This covers cases such as "file system" vs. "filesystem" or "Spell-check" vs. "Spellcheck". It's a matter of professional appearance, and you should really try to make your spelling consistent with that of the other KDE documents.

Not using the most up to date DOCTYPE declaration for your markup means not being able to use the entities which might be suggested below, when checking for applicable entities.

• Found empty <para> element in line 3.

Elements without any content make it impossible to translate the DocBook file into other languages; in particular, the xml2po program which is used by the KDE translation framework will break. You need to remove those elements, or fill them with some dummy content like "FILL ME WITH CONTENT" or such.

People who spent time on translating your document should be given credit appropriately. To do this, you need to specify two special comments in your markup:

<!-- TRANS:ROLES_OF_TRANSLATORS -->
This special comment must appear exactly once in your markup; you should put it at the end of your <authorgroup> element.

<!-- TRANS:CREDIT_FOR_TRANSLATORS -->
There must only be one DocBook file in the directory which has this marker. It needs to be placed at the end of your document, right before the &underFDL; entity.

Not using the most up to date DOCTYPE declaration for your markup means not being able to use the entities which might be suggested below, when checking for applicable entities.

People who spent time on translating your document should be given credit appropriately. To do this, you need to specify two special comments in your markup:

<!-- TRANS:ROLES_OF_TRANSLATORS -->
This special comment must appear exactly once in your markup; you should put it at the end of your <authorgroup> element.

<!-- TRANS:CREDIT_FOR_TRANSLATORS -->
There must only be one DocBook file in the directory which has this marker. It needs to be placed at the end of your document, right before the &underFDL; entity.

• In line 24: Prefer '' over '&kappname;'. (Use the entity for this application instead)

  ..<para>As of release 1.0, &kappname; allows you to hold your data in a relational database. One of the advantages of using this industry-standard format is that it may allow you to view your data using one of the graphic front ends such as OpenOffice.org<trademark class="copyright"/>, perhaps in some format that &kappname; currently doesn't provide. Also, a little knowledge of SQL (Structured Query Language, the language used world-wide to access relational databases) should enable you more easily to extract data to feed into some external program, as for example a budgeting application.</para>..

• In line 26: Prefer '&ie;' over 'i.e.'. (Use the entity!)

  ..<para>It should be noted that the current release of the program merely treats the database in the same fashion as an ordinary file, in that it reads all the data into memory when opened, and writes updated data back when closed. A more conventional method of database access, i.e. reading and updating data only as required, is planned for a future release.</para>..

• In line 32: Prefer '' over '&kappname;'. (Use the entity for this application instead)

  ..<para>To access the database, &kappname; uses the SQL module supplied by Trolltech<trademark class="registered"/> as part of their Qt<trademark class="registered"/> programming system. This module supports a number of different database systems through a collection of drivers. Among the more popular open-source systems for which drivers are available are MySQL<trademark class="registered"/>, SQLite and PostgreSQL The module also supports the 'heavier', more industrial, systems such as Oracle<trademark class="registered"/> and IBM DB2<trademark class="registered"/></para>..

• In line 44: Prefer '&etc;' over 'etc.'. (Use the entity!)

  ..<para>Looking after databases is a little more complex than dealing with regular files. Each system has different methods for performing those necessary administrative tasks such as initial creation, assigning permissions to various users, producing backups etc. Describing these is outside the scope of this manual, but all of the supported products provide comprehensive reference documentation, and a quick search of the web will point you at many tutorials on the subject.</para>..

• In line 57: Prefer '' over '&kappname;'. (Use the entity for this application instead)

  ..<para>On your first usage, &kappname; will attempt to create the necessary table structures. In order to achieve the maximum compatibility between various database types, only a subset of common data types are used. There may nevertheless be situations where a particular type is not supported, and in this case, provision has been made to generate the SQL code necessary to create tables. This code can then be modified as required and used to create the tables outside of &kappname;. Should you find yourself in this situation, help can usually be obtained from &devlist;.</para>..

• In line 73: Prefer '' over '&kappname;'. (Use the entity for this application instead)

  ..<para>The default database name is KMyMoney, but you may choose some other name if you like. SQLite has one database per file; selecting this driver opens the file dialog. For database types other than MySQL, the database name must be pre-created, though &kappname; will create all table structures where necessary.</para>..

• In line 105: Prefer '&eg;' over 'e.g.'. (Use the entity!)

  ..<para>To extract data, e.g. into a spreadsheet or external file, it is almost invariably necessary to select linked data from one or more tables. This is done by 'joining' the tables, using a field which is common to each. You can find a lot more information about how this is done from the online tutorials mentioned above. The following table lists the fields used to define these inter-table relationships.</para>..

• In line 256: Prefer '' over '&kappname;'. (Use the entity for this application instead)

  ..<para>Having data in an industry standard format does give you the ability to modify it outside the &kappname; application. DON'T DO IT unless you really know what you're doing, and always be certain to make a backup copy of your data first. If you get it wrong, &kappname; may not be able to access your data, and you could even end up losing it altogether. You have been warned!</para>..

• In line 262: Prefer 'lowercase' over 'lower-case'.

  ..<para>Most database systems allow you to store commonly used queries and procedures, and in some cases, these may be held as tables within your database itself. As you will have guessed from the above, all the tables used by &kappname; begin with the lower-case letters 'kmm'. This standard will be maintained, and only tables beginning with these letters will be updated. Thus provided you avoid these in the naming of your queries etc., you should not experience any problems.</para>..

• In line 262: Prefer '' over '&kappname;'. (Use the entity for this application instead)

  ..<para>Most database systems allow you to store commonly used queries and procedures, and in some cases, these may be held as tables within your database itself. As you will have guessed from the above, all the tables used by &kappname; begin with the lower-case letters 'kmm'. This standard will be maintained, and only tables beginning with these letters will be updated. Thus provided you avoid these in the naming of your queries etc., you should not experience any problems.</para>..

For the sake of consistency (and proper spelling), there is a centralized list of common phrases and how they should be spelt in KDE manuals. This covers cases such as "file system" vs. "filesystem" or "Spell-check" vs. "Spellcheck". It's a matter of professional appearance, and you should really try to make your spelling consistent with that of the other KDE documents.

Note:It is not guaranteed that the document is still valid after applying these suggestions! If you happen to see a suggestion which would break the document, please send Frerich Raabe a mail about it.

• Entity could be used in line 32:

  -  <para>To access the database, &kappname; uses the SQL module supplied by Trolltech<trademark class="registered"/> as part of their Qt<trademark class="registered"/> programming system. This module supports a number of different database systems through a collection of drivers. Among the more popular open-source systems for which drivers are available are MySQL<trademark class="registered"/>, SQLite and PostgreSQL The module also supports the 'heavier', more industrial, systems such as Oracle<trademark class="registered"/> and IBM DB2<trademark class="registered"/></para>
  +  <para>To access the database, &kappname; uses the SQL module supplied by Trolltech<trademark class="registered"/> as part of their &Qt;<trademark class="registered"/> programming system. This module supports a number of different database systems through a collection of drivers. Among the more popular open-source systems for which drivers are available are MySQL<trademark class="registered"/>, SQLite and PostgreSQL The module also supports the 'heavier', more industrial, systems such as Oracle<trademark class="registered"/> and IBM DB2<trademark class="registered"/></para>
  

• Entity could be used in line 38:

  -  <para>In addition to the database software itself, you must also install the corresponding Qt<trademark class="registered"/> driver module. Most distributions will include driver modules for the more popular databases. Otherwise, check with the <ulink url="http://www.trolltech.com">Trolltech web site </ulink> and search for 'SQL drivers'</para>
  +  <para>In addition to the database software itself, you must also install the corresponding &Qt;<trademark class="registered"/> driver module. Most distributions will include driver modules for the more popular databases. Otherwise, check with the <ulink url="http://www.trolltech.com">Trolltech web site </ulink> and search for 'SQL drivers'</para>
  

• Entity could be used in line 69:

  -This box lists all Qt SQL drivers installed on your system. Select the driver for your database type. If the one you want is not in the list, you need to install the appropriate driver. See your distro documentation, or visit the <ulink url="http://www.trolltech.com/" type="">Trolltech web site</ulink> and search for 'SQL drivers'.
  +This box lists all &Qt; SQL drivers installed on your system. Select the driver for your database type. If the one you want is not in the list, you need to install the appropriate driver. See your distro documentation, or visit the <ulink url="http://www.trolltech.com/" type="">Trolltech web site</ulink> and search for 'SQL drivers'.
  

There are a lot of entities available to authors of KDE manuals which make it easy to keep the spelling of applications and abbreviations consistent. Using them makes sure that application names are capitalized and marked up correctly, licensed terms get proper 'trademark' and 'copyright' signs, keys which are labelled differently in different countries (such as the 'Ctrl' key which is labelled 'Strg' on german keyboards) get automatically translated and more. To make a long story short - you don't lose anything when using entities as much as possible, but you gain a lot.

Not using the most up to date DOCTYPE declaration for your markup means not being able to use the entities which might be suggested below, when checking for applicable entities.

Just like elements without any content, multiple root elements make it impossible to translate the DocBook file into other languages. You should split a file with multiple root elements up into a bunch of files with one root element each.

People who spent time on translating your document should be given credit appropriately. To do this, you need to specify two special comments in your markup:

<!-- TRANS:ROLES_OF_TRANSLATORS -->
This special comment must appear exactly once in your markup; you should put it at the end of your <authorgroup> element.

<!-- TRANS:CREDIT_FOR_TRANSLATORS -->
There must only be one DocBook file in the directory which has this marker. It needs to be placed at the end of your document, right before the &underFDL; entity.

• In line 5: Prefer '&eg;' over 'eg.'. (Use the entity!)

  ..Whenever &kappname; needs information about a specific date, eg. the posting date of a transaction of the opening date of an account,..

• In line 5: Prefer '' over '&kappname;'. (Use the entity for this application instead)

  ..Whenever &kappname; needs information about a specific date, eg. the posting date of a transaction of the opening date of an account,..

• In line 87: Prefer '' over '&kappname;'. (Use the entity for this application instead)

  ..As long as matching entries exist in the list of payees/payers maintained by &kappname; they will be presented in a box beneath or above..

• In line 107: Prefer '' over '&kappname;'. (Use the entity for this application instead)

  ..If a name is entered that is not yet known to &kappname; you will be asked if you wants to create a new payee/payer record...

• In line 116: Prefer '' over '&kappname;'. (Use the entity for this application instead)

  ..As long as matching entries exist in the list of categories/accounts known to &kappname; they will be presented in a box beneath or above..

• In line 136: Prefer '' over '&kappname;'. (Use the entity for this application instead)

  ..If a name is entered that is not yet known to &kappname; you will be asked if you wants to create a new category record...

For the sake of consistency (and proper spelling), there is a centralized list of common phrases and how they should be spelt in KDE manuals. This covers cases such as "file system" vs. "filesystem" or "Spell-check" vs. "Spellcheck". It's a matter of professional appearance, and you should really try to make your spelling consistent with that of the other KDE documents.

Not using the most up to date DOCTYPE declaration for your markup means not being able to use the entities which might be suggested below, when checking for applicable entities.

People who spent time on translating your document should be given credit appropriately. To do this, you need to specify two special comments in your markup:

<!-- TRANS:ROLES_OF_TRANSLATORS -->
This special comment must appear exactly once in your markup; you should put it at the end of your <authorgroup> element.

<!-- TRANS:CREDIT_FOR_TRANSLATORS -->
There must only be one DocBook file in the directory which has this marker. It needs to be placed at the end of your document, right before the &underFDL; entity.

• In line 28: Prefer '' over '&kappname;'. (Use the entity for this application instead)

  ..The Ledgers view is where most of the functionality of &kappname; lies...

• In line 138: Prefer '' over '&kappname;'. (Use the entity for this application instead)

  ..Please note that the actual transaction method is not directly used by &kappname; but is purely for grouping/reporting purposes...

• In line 152: Prefer '' over '&kappname;'. (Use the entity for this application instead)

  ..Enter the required information using the following notes on the available fields. Note that many fields have 'Auto Completion' turned on. That is the field will try and finish your input for you. If you start typing &kappname; will offer alternatives matching the characters you have entered so far. To select an entry click on it using the mouse or keyboard, or if your entry is not listed keep typing to add the new value. The next time you type the value in, &kappname; will find it for you after the first few characters have been input...

• In line 158: Prefer '' over '&kappname;'. (Use the entity for this application instead)

  ..The Payee is who the money came from/to. If the payee is a new entry &kappname; will ask if you wish to add this to the Payees view. Any other information related to a payee, such as the address details can be updated in this view later...

• In line 165: Prefer '' over '&kappname;'. (Use the entity for this application instead)

  ..The Category lets you associate this transaction with another account for accounting purposes and to let you create reports and or group certain transactions. Type the name of the category into the required field. If you have entered the category and it does not exist then &kappname; will prompt you to create a new one...

• In line 168: Prefer '' over '&kappname;'. (Use the entity for this application instead)

  ..If this transaction is a multipart transaction, i.e you wish to associate the transaction with more than one category, &kappname; can let you do that. An example transaction might be a cash machine withdrawal of 50 that you use 10 on food, 20 on beer and 20 as spare cash. The transaction will therefore be assigned three categories, Food, Beer and Cash. To assign these categories to the transaction click on the <guibutton>Split</guibutton> button. This brings up the <link linkend="details.ledgers.split">Split Editor</link>. Enter the categories, creating any new ones as needed, and input the amount per category. Click on <guibutton>OK</guibutton> to save the assignments. Note that the category field in the transaction input form now displays <emphasis>Split transaction</emphasis>..

• In line 189: Prefer '' over '&kappname;'. (Use the entity for this application instead)

  ..The transaction date can also be entered to specify when the transaction took place. See the special &kappname; fields section for more information on the date input field and it can be used to make entering dates quicker and easier...

• In line 228: Prefer '' over '&kappname;'. (Use the entity for this application instead)

  ..To do this you must first let &kappname; know that you don't want to use the transaction from by opening the settings dialog and unchecking the <guilabel>Use transaction form</guilabel> option...

• In line 232: Prefer 'menubar' over 'menu bar'.

  ..This is performed by selecting <guimenu>Settings</guimenu><guimenuitem>Configure &kappname;</guimenuitem> from the menu bar and selecting the <guiicon><inlinemediaobject><imageobject><imagedata fileref="register.png"></imagedata></imageobject></inlinemediaobject>Register</guiicon> icon from the list on left. The option to uncheck is labelled <guilabel>Show transaction form</guilabel>. When finished click on <guibutton>OK</guibutton> to be ready to directly enter transactions...

• In line 309: Prefer '' over '&kappname;'. (Use the entity for this application instead)

  ..The solution is to tell &kappname; that the transactions are the same, using the manual matching interface...

For the sake of consistency (and proper spelling), there is a centralized list of common phrases and how they should be spelt in KDE manuals. This covers cases such as "file system" vs. "filesystem" or "Spell-check" vs. "Spellcheck". It's a matter of professional appearance, and you should really try to make your spelling consistent with that of the other KDE documents.

Not using the most up to date DOCTYPE declaration for your markup means not being able to use the entities which might be suggested below, when checking for applicable entities.

• Found empty <para> element in line 3.

Elements without any content make it impossible to translate the DocBook file into other languages; in particular, the xml2po program which is used by the KDE translation framework will break. You need to remove those elements, or fill them with some dummy content like "FILL ME WITH CONTENT" or such.

People who spent time on translating your document should be given credit appropriately. To do this, you need to specify two special comments in your markup:

<!-- TRANS:ROLES_OF_TRANSLATORS -->
This special comment must appear exactly once in your markup; you should put it at the end of your <authorgroup> element.

<!-- TRANS:CREDIT_FOR_TRANSLATORS -->
There must only be one DocBook file in the directory which has this marker. It needs to be placed at the end of your document, right before the &underFDL; entity.

Not using the most up to date DOCTYPE declaration for your markup means not being able to use the entities which might be suggested below, when checking for applicable entities.

People who spent time on translating your document should be given credit appropriately. To do this, you need to specify two special comments in your markup:

<!-- TRANS:ROLES_OF_TRANSLATORS -->
This special comment must appear exactly once in your markup; you should put it at the end of your <authorgroup> element.

<!-- TRANS:CREDIT_FOR_TRANSLATORS -->
There must only be one DocBook file in the directory which has this marker. It needs to be placed at the end of your document, right before the &underFDL; entity.

• In line 23: Prefer 'they are' over 'they're'.

  ..Stocks, bonds, and mutual funds are the most common investments, so they're the ones supported most directly...

• In line 24: Prefer '' over '&kappname;'. (Use the entity for this application instead)

  ..Futures, commodities, options and more complex derivatives are also sometimes used, but &kappname; has no special functionality for them. As long as they behave like a stock or a bond, they can be tracked easily...

• In line 184: Prefer '' over '&kappname;'. (Use the entity for this application instead)

  ..You can enter any two of these, and &kappname; will calculate the third...

• In line 208: Prefer '' over '&kappname;'. (Use the entity for this application instead)

  ..Now that &kappname; supports multiple currencies and investments, you'd probably like to combine the two...

• In line 329: Prefer '' over '&kappname;'. (Use the entity for this application instead)

  ..<guimenuitem>Update Stock and Currency Prices...</guimenuitem> </menuchoice> menu option to bring up the online price quotes dialog. Press <guibutton>Update All</guibutton> to fetch quotes for all investments and currencies in your &kappname; file...

For the sake of consistency (and proper spelling), there is a centralized list of common phrases and how they should be spelt in KDE manuals. This covers cases such as "file system" vs. "filesystem" or "Spell-check" vs. "Spellcheck". It's a matter of professional appearance, and you should really try to make your spelling consistent with that of the other KDE documents.

Note:It is not guaranteed that the document is still valid after applying these suggestions! If you happen to see a suggestion which would break the document, please send Frerich Raabe a mail about it.

• Entity could be used in line 350:

  -	You should feel comfortable reading HTML, and writing complex regular expressions.
  +	You should feel comfortable reading &HTML;, and writing complex regular expressions.
  

• Entity could be used in line 364:

  -	The first thing to worry about in an online quote source is the URL.
  +	The first thing to worry about in an online quote source is the &URL;.
  

• Entity could be used in line 368:

  -	This URL is then fetched, all HTML tags are removed, and that stripped file is then sent to the page parser.
  +	This &URL; is then fetched, all &HTML; tags are removed, and that stripped file is then sent to the page parser.
  

• Entity could be used in line 371:

  -	Note that the URL can also be a file: URL, which the quote fetcher takes to mean an executable script.
  +	Note that the &URL; can also be a file: &URL;, which the quote fetcher takes to mean an executable script.
  

• Entity could be used in line 374:

  -	Your URL would be "file:/path/to/getquote.sh %1".
  +	Your &URL; would be "file:/path/to/getquote.sh %1".
  

There are a lot of entities available to authors of KDE manuals which make it easy to keep the spelling of applications and abbreviations consistent. Using them makes sure that application names are capitalized and marked up correctly, licensed terms get proper 'trademark' and 'copyright' signs, keys which are labelled differently in different countries (such as the 'Ctrl' key which is labelled 'Strg' on german keyboards) get automatically translated and more. To make a long story short - you don't lose anything when using entities as much as possible, but you gain a lot.

Not using the most up to date DOCTYPE declaration for your markup means not being able to use the entities which might be suggested below, when checking for applicable entities.

• Found empty <para> element in line 4.

Elements without any content make it impossible to translate the DocBook file into other languages; in particular, the xml2po program which is used by the KDE translation framework will break. You need to remove those elements, or fill them with some dummy content like "FILL ME WITH CONTENT" or such.

People who spent time on translating your document should be given credit appropriately. To do this, you need to specify two special comments in your markup:

<!-- TRANS:ROLES_OF_TRANSLATORS -->
This special comment must appear exactly once in your markup; you should put it at the end of your <authorgroup> element.

<!-- TRANS:CREDIT_FOR_TRANSLATORS -->
There must only be one DocBook file in the directory which has this marker. It needs to be placed at the end of your document, right before the &underFDL; entity.

Not using the most up to date DOCTYPE declaration for your markup means not being able to use the entities which might be suggested below, when checking for applicable entities.

People who spent time on translating your document should be given credit appropriately. To do this, you need to specify two special comments in your markup:

<!-- TRANS:ROLES_OF_TRANSLATORS -->
This special comment must appear exactly once in your markup; you should put it at the end of your <authorgroup> element.

<!-- TRANS:CREDIT_FOR_TRANSLATORS -->
There must only be one DocBook file in the directory which has this marker. It needs to be placed at the end of your document, right before the &underFDL; entity.

Not using the most up to date DOCTYPE declaration for your markup means not being able to use the entities which might be suggested below, when checking for applicable entities.

People who spent time on translating your document should be given credit appropriately. To do this, you need to specify two special comments in your markup:

<!-- TRANS:ROLES_OF_TRANSLATORS -->
This special comment must appear exactly once in your markup; you should put it at the end of your <authorgroup> element.

<!-- TRANS:CREDIT_FOR_TRANSLATORS -->
There must only be one DocBook file in the directory which has this marker. It needs to be placed at the end of your document, right before the &underFDL; entity.

• In line 19: Prefer '' over '&kappname;'. (Use the entity for this application instead)

  ..This chapter describes the formats in which &kappname; stores it's data in permanent form on the users disk. In..

• In line 20: Prefer '' over '&kappname;'. (Use the entity for this application instead)

  ..general, &kappname; stores it's information in form of an XML document. Depending on the actual format, this..

• In line 43: Prefer '' over '&kappname;'. (Use the entity for this application instead)

  ..working of &kappname; is fully understood or instructions from the developers tell you what to do. Don't blame the..

• In line 53: Prefer '' over '&kappname;'. (Use the entity for this application instead)

  ..This is the normal format used by &kappname; when you store a file with the extension <literal role="extension">.kmy</literal>..

• In line 61: Prefer '' over '&kappname;'. (Use the entity for this application instead)

  ..If you want to look at a GZIP compressed file, rename it to a filename ending in <literal role="extension">.gz</literal> (e.g. <filename>myfinances.kmy</filename> into <filename>myfinances.kmy.gz</filename>, then use <command>gunzip</command> to uncompress the file and look at it. You don't have to compress it before loading it into &kappname; the next time, because &kappname; can read the uncompressed data as well. Nevertheless, if you save it thereafter, it will be saved compressed again. Use the <link linkend="details.formats.plain">.xml</link> extension to write it in uncompressed format...

• In line 68: Prefer '' over '&kappname;'. (Use the entity for this application instead)

  ..Using the GPG-encrpyted file format is a very secure method to store your personal finance data on your disk. When &kappname; has been instructed through the settings dialog to store your data encrypted, it will cipher the data using GPG and the key you provided before actually storing it on disk. When opening an encrypted file, you have to provide the passphrase necessary to open your keyring. The encrypted file itself will be stored in GPG's <emphasis>ASCII armored</emphasis> format...

• In line 91: Prefer 'email' over 'e-mail'.

  ..On the encryption page of the settings dialog you have a field where you can enter the key-id of the key that should be used for encryption and decryption. You can use either the key-id, the e-mail address associated with this key or any other valid GPG key identification as value for this field. When you enter the key-id, &kappname; will check it's validity and turn on a green LED in the dialog if a key is found...

• In line 91: Prefer '' over '&kappname;'. (Use the entity for this application instead)

  ..On the encryption page of the settings dialog you have a field where you can enter the key-id of the key that should be used for encryption and decryption. You can use either the key-id, the e-mail address associated with this key or any other valid GPG key identification as value for this field. When you enter the key-id, &kappname; will check it's validity and turn on a green LED in the dialog if a key is found...

• In line 101: Prefer '' over '&kappname;'. (Use the entity for this application instead)

  ..<title>The &kappname; recover key</title>..

• In line 103: Prefer '' over '&kappname;'. (Use the entity for this application instead)

  ..Also on this page of the settings dialog you have the choice to select supplemental encryption with the &kappname; recover key. This option is available to you, if that key is stored in your <application>GPG</application> keyring. Selecting this option will allow you to recover your data even in the case you loose your own private key. This is possible, because the data is not only encrypted for your own key, but also for the &kappname; recover key. This key is only available to selected &kappname; developers (at the time of writing only to the author)...

• In line 106: Prefer 'email' over 'e-mail'.

  ..Under normal circumstances, you will open/save/close your file as usual. In the abnormal case of loss of your key, you have the chance to contact one of the developers who has access to the &kappname; recover key and request help to recover your data. You may contact the developers via e-mail to the &kappname; developer mailing list at &devlist;...

• In line 106: Prefer '' over '&kappname;'. (Use the entity for this application instead)

  ..Under normal circumstances, you will open/save/close your file as usual. In the abnormal case of loss of your key, you have the chance to contact one of the developers who has access to the &kappname; recover key and request help to recover your data. You may contact the developers via e-mail to the &kappname; developer mailing list at &devlist;...

• In line 114: Prefer '' over '&kappname;'. (Use the entity for this application instead)

  ..This format is not intended to be used for normal data storage. It is supported as a method to supply the &kappname; development team with your file in case of a problem without disclosing any of your financial data. If instructed by the developers use the <guimenuitem>Save as...</guimenuitem> menu item to store your data in anonymous format by selecting <literal role="extension">.anon.xml</literal> as file extension. To verify that your problem still exists, reload this anonymized file and try to duplicate your problem. If it shows, send the file to the developer mailing list at &devlist; for further investigation. If the problem does not show ... well, I don't want to think about this scenario right now...

For the sake of consistency (and proper spelling), there is a centralized list of common phrases and how they should be spelt in KDE manuals. This covers cases such as "file system" vs. "filesystem" or "Spell-check" vs. "Spellcheck". It's a matter of professional appearance, and you should really try to make your spelling consistent with that of the other KDE documents.

Note:It is not guaranteed that the document is still valid after applying these suggestions! If you happen to see a suggestion which would break the document, please send Frerich Raabe a mail about it.

• Entity could be used in line 20:

  -general, &kappname; stores it's information in form of an XML document. Depending on the actual format, this
  -XML document will be written
  +general, &kappname; stores it's information in form of an &XML; document. Depending on the actual format, this
  +&XML; document will be written
  

There are a lot of entities available to authors of KDE manuals which make it easy to keep the spelling of applications and abbreviations consistent. Using them makes sure that application names are capitalized and marked up correctly, licensed terms get proper 'trademark' and 'copyright' signs, keys which are labelled differently in different countries (such as the 'Ctrl' key which is labelled 'Strg' on german keyboards) get automatically translated and more. To make a long story short - you don't lose anything when using entities as much as possible, but you gain a lot.

Not using the most up to date DOCTYPE declaration for your markup means not being able to use the entities which might be suggested below, when checking for applicable entities.

People who spent time on translating your document should be given credit appropriately. To do this, you need to specify two special comments in your markup:

<!-- TRANS:ROLES_OF_TRANSLATORS -->
This special comment must appear exactly once in your markup; you should put it at the end of your <authorgroup> element.

<!-- TRANS:CREDIT_FOR_TRANSLATORS -->
There must only be one DocBook file in the directory which has this marker. It needs to be placed at the end of your document, right before the &underFDL; entity.

• In line 28: Prefer '' over '&kappname;'. (Use the entity for this application instead)

  ..The &kappname; GnuCash importer handles direct reading of standard (XML)..

• In line 34: Prefer '' over '&kappname;'. (Use the entity for this application instead)

  ..<listitem><para>import into an existing &kappname; file</para></listitem>..

• In line 74: Prefer '' over '&kappname;'. (Use the entity for this application instead)

  ..It should be noted that &kappname; is..

• In line 87: Prefer '' over '&kappname;'. (Use the entity for this application instead)

  ..the account. &kappname; supports 5 main types of account, Asset, Liability,..

• In line 91: Prefer '' over '&kappname;'. (Use the entity for this application instead)

  ..all other accounts are held subordinate to one of these. &kappname; enforces..

• In line 115: Prefer '' over '&kappname;'. (Use the entity for this application instead)

  ..structure, as a holder for other accounts. Though &kappname; does not..

• In line 124: Prefer '' over '&kappname;'. (Use the entity for this application instead)

  ..<title>Equivalence of GnuCash and &kappname; account types</title>..

• In line 184: Prefer '' over '&kappname;'. (Use the entity for this application instead)

  ..balance (i.e. must balance out to zero). &kappname; encourages, but does not..

• In line 230: Prefer '' over '&kappname;'. (Use the entity for this application instead)

  ..(NOTE: &kappname; does not currently support accounts denominated in 'defunct' currencies..

• In line 241: Prefer '' over '&kappname;'. (Use the entity for this application instead)

  ..products, in that &kappname; requires any account denominated in a security..

• In line 277: Prefer '' over '&kappname;'. (Use the entity for this application instead)

  ..a package called Finance::Quote. &kappname; does not support this at present, and has..

• In line 372: Prefer '' over '&kappname;'. (Use the entity for this application instead)

  ..any case should be reported to the &kappname; developer list &devlist;...

• In line 432: Prefer '' over '&kappname;'. (Use the entity for this application instead)

  ..To import a QIF file, first ensure you have a valid &kappname; file open. Then select <guimenuitem>Import</guimenuitem> <guimenuitem>Qif</guimenuitem> from the <guimenu>File</guimenu> menu...

• In line 450: Prefer '' over '&kappname;'. (Use the entity for this application instead)

  ..If you want &kappname; to automatically enter new payees check the appropriate option otherwise &kappname; will prompt you each time a new payee is found...

• In line 493: Prefer '' over '&kappname;'. (Use the entity for this application instead)

  ..When &kappname; has finished importing the QIF transactions the account will be shown with the imported transactions listed in Yellow...

• In line 525: Prefer '' over '&kappname;'. (Use the entity for this application instead)

  ..Please note that if you are importing a file with investment transactions, those investments must first exist in your &kappname; file...

• In line 526: Prefer '' over '&kappname;'. (Use the entity for this application instead)

  ..The trading symbol is used to match, so please ensure that the symbol in &kappname; is exactly the same as the one in the file you're importing...

• In line 535: Prefer '' over '&kappname;'. (Use the entity for this application instead)

  ..This profile tells &kappname; about the peculiarities of your file...

• In line 611: Prefer '' over '&kappname;'. (Use the entity for this application instead)

  ..You can still import that file into &kappname; using a QIF Import Filter...

• In line 643: Prefer '' over '&kappname;'. (Use the entity for this application instead)

  ..<sect2><title>Special &kappname; QIF extensions</title>..

• In line 689: Prefer '' over '&kappname;'. (Use the entity for this application instead)

  ..It should be available from whatever source you got the base &kappname; RPM...

• In line 691: Prefer '' over '&kappname;'. (Use the entity for this application instead)

  ..The &kappname; build process will detect these and compile the plugin...

• In line 726: Prefer '' over '&kappname;'. (Use the entity for this application instead)

  ..Please note that if you are importing a file with investment transactions, those investments must first exist in your &kappname; file...

• In line 727: Prefer '' over '&kappname;'. (Use the entity for this application instead)

  ..The trading symbol is used to match, so please ensure that the symbol in &kappname; is exactly the same as the one in the file you're importing...

• In line 738: Prefer '' over '&kappname;'. (Use the entity for this application instead)

  ..It will then import the downloaded OFX file into the &kappname; file you most recently had open...

• In line 741: Prefer '' over '&kappname;'. (Use the entity for this application instead)

  ..If you need to import the OFX file into some other &kappname; file, load up that file in &kappname; first, and then visit your bank...

• In line 753: Prefer '' over '&kappname;'. (Use the entity for this application instead)

  ..To enable this, you must compile &kappname; with the --enable-ofxbanking switch...

For the sake of consistency (and proper spelling), there is a centralized list of common phrases and how they should be spelt in KDE manuals. This covers cases such as "file system" vs. "filesystem" or "Spell-check" vs. "Spellcheck". It's a matter of professional appearance, and you should really try to make your spelling consistent with that of the other KDE documents.

Note:It is not guaranteed that the document is still valid after applying these suggestions! If you happen to see a suggestion which would break the document, please send Frerich Raabe a mail about it.

• Entity could be used in line 28:

  -The &kappname; GnuCash importer handles direct reading of standard (XML)
  +The &kappname; GnuCash importer handles direct reading of standard (&XML;)
  

There are a lot of entities available to authors of KDE manuals which make it easy to keep the spelling of applications and abbreviations consistent. Using them makes sure that application names are capitalized and marked up correctly, licensed terms get proper 'trademark' and 'copyright' signs, keys which are labelled differently in different countries (such as the 'Ctrl' key which is labelled 'Strg' on german keyboards) get automatically translated and more. To make a long story short - you don't lose anything when using entities as much as possible, but you gain a lot.

Not using the most up to date DOCTYPE declaration for your markup means not being able to use the entities which might be suggested below, when checking for applicable entities.

• Found empty <para> element in line 24.
• Found empty <para> element in line 29.
• Found empty <para> element in line 34.
• Found empty <para> element in line 41.
• Found empty <para> element in line 45.
• Found empty <para> element in line 49.
• Found empty <para> element in line 56.
• Found empty <para> element in line 60.
• Found empty <para> element in line 65.
• Found empty <para> element in line 70.
• Found empty <para> element in line 76.
• Found empty <para> element in line 80.
• Found empty <para> element in line 85.
• Found empty <para> element in line 89.
• Found empty <para> element in line 94.
• Found empty <para> element in line 100.

Elements without any content make it impossible to translate the DocBook file into other languages; in particular, the xml2po program which is used by the KDE translation framework will break. You need to remove those elements, or fill them with some dummy content like "FILL ME WITH CONTENT" or such.

People who spent time on translating your document should be given credit appropriately. To do this, you need to specify two special comments in your markup:

<!-- TRANS:ROLES_OF_TRANSLATORS -->
This special comment must appear exactly once in your markup; you should put it at the end of your <authorgroup> element.

<!-- TRANS:CREDIT_FOR_TRANSLATORS -->
There must only be one DocBook file in the directory which has this marker. It needs to be placed at the end of your document, right before the &underFDL; entity.

• In line 95: Prefer '' over '&kappname;'. (Use the entity for this application instead)

  ..<sect2 id="views.schedule.autoenter"><title>Letting &kappname; enter the schedules</title>..

For the sake of consistency (and proper spelling), there is a centralized list of common phrases and how they should be spelt in KDE manuals. This covers cases such as "file system" vs. "filesystem" or "Spell-check" vs. "Spellcheck". It's a matter of professional appearance, and you should really try to make your spelling consistent with that of the other KDE documents.

Not using the most up to date DOCTYPE declaration for your markup means not being able to use the entities which might be suggested below, when checking for applicable entities.

• Found empty <para> element in line 3.

Elements without any content make it impossible to translate the DocBook file into other languages; in particular, the xml2po program which is used by the KDE translation framework will break. You need to remove those elements, or fill them with some dummy content like "FILL ME WITH CONTENT" or such.

People who spent time on translating your document should be given credit appropriately. To do this, you need to specify two special comments in your markup:

<!-- TRANS:ROLES_OF_TRANSLATORS -->
This special comment must appear exactly once in your markup; you should put it at the end of your <authorgroup> element.

<!-- TRANS:CREDIT_FOR_TRANSLATORS -->
There must only be one DocBook file in the directory which has this marker. It needs to be placed at the end of your document, right before the &underFDL; entity.

Not using the most up to date DOCTYPE declaration for your markup means not being able to use the entities which might be suggested below, when checking for applicable entities.

• Found empty <para> element in line 3.

Elements without any content make it impossible to translate the DocBook file into other languages; in particular, the xml2po program which is used by the KDE translation framework will break. You need to remove those elements, or fill them with some dummy content like "FILL ME WITH CONTENT" or such.

People who spent time on translating your document should be given credit appropriately. To do this, you need to specify two special comments in your markup:

<!-- TRANS:ROLES_OF_TRANSLATORS -->
This special comment must appear exactly once in your markup; you should put it at the end of your <authorgroup> element.

<!-- TRANS:CREDIT_FOR_TRANSLATORS -->
There must only be one DocBook file in the directory which has this marker. It needs to be placed at the end of your document, right before the &underFDL; entity.

Not using the most up to date DOCTYPE declaration for your markup means not being able to use the entities which might be suggested below, when checking for applicable entities.

People who spent time on translating your document should be given credit appropriately. To do this, you need to specify two special comments in your markup:

<!-- TRANS:ROLES_OF_TRANSLATORS -->
This special comment must appear exactly once in your markup; you should put it at the end of your <authorgroup> element.

<!-- TRANS:CREDIT_FOR_TRANSLATORS -->
There must only be one DocBook file in the directory which has this marker. It needs to be placed at the end of your document, right before the &underFDL; entity.

• In line 19: Prefer '' over '&kappname;'. (Use the entity for this application instead)

  ..<title>Using &kappname; for the first time</title>..

• In line 22: Prefer '' over '&kappname;'. (Use the entity for this application instead)

  ..<title>Running &kappname; for the first time</title>..

• In line 25: Prefer '' over '&kappname;'. (Use the entity for this application instead)

  ..After starting &kappname; and the application has fully loaded two windows will be opened. The top most window, 'Tip of the Day' presents a method for the application to let you know about important or useful pieces of information...

• In line 44: Prefer '' over '&kappname;'. (Use the entity for this application instead)

  ..Once you have read the tips the window can be closed and will re-open each time &kappname; is started. To stop this default behavior uncheck the appropriate option on the Tip of the Day window...

• In line 78: Prefer '' over '&kappname;'. (Use the entity for this application instead)

  ..The &kappname; main window consists of four major parts..

• In line 90: Prefer '' over '&kappname;'. (Use the entity for this application instead)

  ..The menu and toolbars provide access to the features of &kappname; and allow you to <link linkend="firsttime-3">Create</link> files or configure how &kappname; operates...

• In line 290: Prefer '' over '&kappname;'. (Use the entity for this application instead)

  ..Because all fields are optional, you can use &kappname; without entering any information now. Any information entered here is used only to personalize your file. In the future, it may be used in some reports and for online banking. If &kappname; requires any personal information in future releases and finds none, you will be prompted to enter the relevant data then...

• In line 300: Prefer '' over '&kappname;'. (Use the entity for this application instead)

  ..Because this is a new file &kappname; will now import a set of default accounts with your interaction. A message box is first shown reminding you that this step involves selecting the correct file to import into &kappname;...

• In line 320: Prefer 'folders' over 'directories'. (Only use 'directory' for CLI)

  ..Next &kappname; shows the standard KDE File Open dialog box allowing you to select the appropriate file for your country/region. This window should list various language dependant directories containing files ending with the file extension 'kmt'. If no files are listed matching this criteria then please navigate to $KDEDIR/share/apps/kmymoney2. On a Mandrake 10 System this relates to /usr/share/apps/kmymoney2...

• In line 320: Prefer '' over '&kappname;'. (Use the entity for this application instead)

  ..Next &kappname; shows the standard KDE File Open dialog box allowing you to select the appropriate file for your country/region. This window should list various language dependant directories containing files ending with the file extension 'kmt'. If no files are listed matching this criteria then please navigate to $KDEDIR/share/apps/kmymoney2. On a Mandrake 10 System this relates to /usr/share/apps/kmymoney2...

• In line 341: Prefer '' over '&kappname;'. (Use the entity for this application instead)

  ..After &kappname; has finished loading the default accounts your financial summary will be displayed. As you have defined no accounts to hold your transactions this is currently empty...

• In line 361: Prefer '' over '&kappname;'. (Use the entity for this application instead)

  ..Note that &kappname; uses the context menus a lot throughout the whole application. If you find yourself stuck trying to figure out how to do something, try right-clicking where you would expect to see a feature...

• In line 375: Prefer '' over '&kappname;'. (Use the entity for this application instead)

  ..Now that one or more accounts exist in &kappname; your account summary is shown in the Home view. You can create transactions manually in the <link linkend="details.ledgers">Ledger</link> view, or set up automatic transactions through the <link linkend="details.schedules">Schedule</link> view...

• In line 383: Prefer '' over '&kappname;'. (Use the entity for this application instead)

  ..A <link linkend="details.schedules">Schedule</link> is a transaction that occurs one or more times over a certain period of time. Sometimes called recurring transactions a typical example is your pay check that you receive every month or week. Rather than have to enter the transaction details each time you get paid, you can instruct &kappname; to create a schedule that will enter a transaction for you when you get paid...

• In line 408: Prefer '' over '&kappname;'. (Use the entity for this application instead)

  ..If you currently use a financial manager application &kappname; can then import an account's transactions as long as they are in the Quicken Interchange Format (QIF). Most financial programs can export this format and the different applications methods of exporting QIF is not discussed here for brevity...

• In line 441: Prefer 'drop down box' over 'drop down list'.

  ..To reconcile an account click on the <guiicon><inlinemediaobject><imageobject><imagedata fileref="reconcile.png"/></imageobject></inlinemediaobject> Reconcile Ledgers</guiicon> icon in the account selector, choose your account from the drop down list and then click on the <guibutton>Reconcile</guibutton> button...

• In line 453: Prefer '' over '&kappname;'. (Use the entity for this application instead)

  ..Now that you have created some accounts and entered transactions its a good idea to perform a backup. Because the file used by &kappname; is a standard Unix file you can just copy the file to another location to back it up or use the dialog provided by &kappname;. Using the dialog is the preferred method because if &kappname; ever starts using other file formats, such as SQL, then it would be much harder to copy the file manually...

• In line 457: Prefer 'folder' over 'directory'. (Only use 'directory' for CLI)

  ..To backup your file through &kappname; Select <guimenuitem>Backup</guimenuitem> from the <guimenu>File</guimenu> menu and enter the directory where you wish the file to be copied to. If the directory needs mounting first and you have the sufficient privileges then check the tick box labelled <guilabel>Mount this directory before backing up</guilabel> and click on <guibutton>OK</guibutton>...

• In line 457: Prefer '' over '&kappname;'. (Use the entity for this application instead)

  ..To backup your file through &kappname; Select <guimenuitem>Backup</guimenuitem> from the <guimenu>File</guimenu> menu and enter the directory where you wish the file to be copied to. If the directory needs mounting first and you have the sufficient privileges then check the tick box labelled <guilabel>Mount this directory before backing up</guilabel> and click on <guibutton>OK</guibutton>...

• In line 461: Prefer 'folder' over 'directory'. (Only use 'directory' for CLI)

  ..The file will be coped to the directory specified with the current date appended to the filename so it is easy to see the date the file was backed up...

• In line 477: Prefer '' over '&kappname;'. (Use the entity for this application instead)

  ..To report a bug please use the interface provided by &kappname; by selecting <menuchoice><guimenu>Help</guimenu><guimenuitem>Report Bug</guimenuitem></menuchoice> and filling in the required information...

• In line 482: Prefer 'emails' over 'e-mails'.

  ..This reduces wasted effort on all sides, as the reporter and the developer who will fix it trade e-mails until this information is really in place...

• In line 490: Prefer '' over '&kappname;'. (Use the entity for this application instead)

  ..The <menuchoice><guimenu>Help</guimenu><guimenuitem>Report Bug</guimenuitem></menuchoice> menu choice will fill this in automatically. But if you would prefer not to use this interface, we will need to know the version of &kappname; you're running, the version of KDE, the name and version of your distribution, and the version of your kernel...

• In line 504: Prefer '' over '&kappname;'. (Use the entity for this application instead)

  ..<formalpara><title>Include specific steps</title><para>This is a bad bug: &quot;I entered a transaction, and &kappname; crashed.&quot; A much better bug is: &quot;Using the transaction form, I entered a new transaction in my Credit Card account. I selected the Transfer tab, entered in an amount, then changed to the Deposit tab, and back to the Transfer tab. When I returned to the Transfer tab, &kappname; crashed. This bug is fully reproducable for me.&quot;</para>..

• In line 510: Prefer '' over '&kappname;'. (Use the entity for this application instead)

  ..<formalpara><title>Consider running with debugging enabled</title><para>By compiling a version configured with --enable-debug=full you can ensure that the best possible backtraces are generated. If you encounter a crash, run &kappname; again from within gdb, and reproduce the crash. When it crashes, type &quot;bt&quot; to generate a backtrace.</para>..

• In line 513: Prefer '' over '&kappname;'. (Use the entity for this application instead)

  ..<para>Running this way is a bit more difficult, so we don't expect all users to do this. However, if you're interested in helping &kappname; become as stable as possible, this is the best way to do it short of finding the bug in the code and sending in a patch.</para>..

For the sake of consistency (and proper spelling), there is a centralized list of common phrases and how they should be spelt in KDE manuals. This covers cases such as "file system" vs. "filesystem" or "Spell-check" vs. "Spellcheck". It's a matter of professional appearance, and you should really try to make your spelling consistent with that of the other KDE documents.

Note:It is not guaranteed that the document is still valid after applying these suggestions! If you happen to see a suggestion which would break the document, please send Frerich Raabe a mail about it.

• Entity could be used in line 320:

  -	Next &kappname; shows the standard KDE File Open dialog box allowing you to select the appropriate file for your country/region.  This window should list various language dependant directories containing files ending with the file extension 'kmt'.  If no files are listed matching this criteria then please navigate to $KDEDIR/share/apps/kmymoney2.  On a Mandrake 10 System this relates to /usr/share/apps/kmymoney2.
  +	Next &kappname; shows the standard &kde; File Open dialog box allowing you to select the appropriate file for your country/region.  This window should list various language dependant directories containing files ending with the file extension 'kmt'.  If no files are listed matching this criteria then please navigate to $KDEDIR/share/apps/kmymoney2.  On a &Mandrake; 10 System this relates to /usr/share/apps/kmymoney2.
  

• Entity could be used in line 490:

  -The  <menuchoice><guimenu>Help</guimenu><guimenuitem>Report Bug</guimenuitem></menuchoice> menu choice will fill this in automatically.  But if you would prefer not to use this interface, we will need to know the version of &kappname; you're running, the version of KDE, the name and version of your distribution, and the version of your kernel.
  +The  <menuchoice><guimenu>Help</guimenu><guimenuitem>Report Bug</guimenuitem></menuchoice> menu choice will fill this in automatically.  But if you would prefer not to use this interface, we will need to know the version of &kappname; you're running, the version of &kde;, the name and version of your distribution, and the version of your kernel.
  

There are a lot of entities available to authors of KDE manuals which make it easy to keep the spelling of applications and abbreviations consistent. Using them makes sure that application names are capitalized and marked up correctly, licensed terms get proper 'trademark' and 'copyright' signs, keys which are labelled differently in different countries (such as the 'Ctrl' key which is labelled 'Strg' on german keyboards) get automatically translated and more. To make a long story short - you don't lose anything when using entities as much as possible, but you gain a lot.

Not using the most up to date DOCTYPE declaration for your markup means not being able to use the entities which might be suggested below, when checking for applicable entities.

People who spent time on translating your document should be given credit appropriately. To do this, you need to specify two special comments in your markup:

<!-- TRANS:ROLES_OF_TRANSLATORS -->
This special comment must appear exactly once in your markup; you should put it at the end of your <authorgroup> element.

<!-- TRANS:CREDIT_FOR_TRANSLATORS -->
There must only be one DocBook file in the directory which has this marker. It needs to be placed at the end of your document, right before the &underFDL; entity.

Not using the most up to date DOCTYPE declaration for your markup means not being able to use the entities which might be suggested below, when checking for applicable entities.

• Found empty <para> element in line 3.

Elements without any content make it impossible to translate the DocBook file into other languages; in particular, the xml2po program which is used by the KDE translation framework will break. You need to remove those elements, or fill them with some dummy content like "FILL ME WITH CONTENT" or such.

People who spent time on translating your document should be given credit appropriately. To do this, you need to specify two special comments in your markup:

<!-- TRANS:ROLES_OF_TRANSLATORS -->
This special comment must appear exactly once in your markup; you should put it at the end of your <authorgroup> element.

<!-- TRANS:CREDIT_FOR_TRANSLATORS -->
There must only be one DocBook file in the directory which has this marker. It needs to be placed at the end of your document, right before the &underFDL; entity.

Not using the most up to date DOCTYPE declaration for your markup means not being able to use the entities which might be suggested below, when checking for applicable entities.

• Found empty <para> element in line 3.

Elements without any content make it impossible to translate the DocBook file into other languages; in particular, the xml2po program which is used by the KDE translation framework will break. You need to remove those elements, or fill them with some dummy content like "FILL ME WITH CONTENT" or such.

People who spent time on translating your document should be given credit appropriately. To do this, you need to specify two special comments in your markup:

<!-- TRANS:ROLES_OF_TRANSLATORS -->
This special comment must appear exactly once in your markup; you should put it at the end of your <authorgroup> element.

<!-- TRANS:CREDIT_FOR_TRANSLATORS -->
There must only be one DocBook file in the directory which has this marker. It needs to be placed at the end of your document, right before the &underFDL; entity.

Not using the most up to date DOCTYPE declaration for your markup means not being able to use the entities which might be suggested below, when checking for applicable entities.

People who spent time on translating your document should be given credit appropriately. To do this, you need to specify two special comments in your markup:

<!-- TRANS:ROLES_OF_TRANSLATORS -->
This special comment must appear exactly once in your markup; you should put it at the end of your <authorgroup> element.

<!-- TRANS:CREDIT_FOR_TRANSLATORS -->
There must only be one DocBook file in the directory which has this marker. It needs to be placed at the end of your document, right before the &underFDL; entity.

• In line 24: Prefer '' over '&kappname;'. (Use the entity for this application instead)

  ..Once you create a &kappname; file you will be asked for the base currency. The base currency is the one that all income and expense categories use and that the reports will be based on. Usually, the base currency is the currency you use in your country. Once selected, the base currency cannot be changed. If not otherwise selected, new accounts will use this currency as the default...

• In line 84: Prefer '' over '&kappname;'. (Use the entity for this application instead)

  ..In &kappname; a &quot;Price&quot; is the price of one currency in terms of another...

For the sake of consistency (and proper spelling), there is a centralized list of common phrases and how they should be spelt in KDE manuals. This covers cases such as "file system" vs. "filesystem" or "Spell-check" vs. "Spellcheck". It's a matter of professional appearance, and you should really try to make your spelling consistent with that of the other KDE documents.

Not using the most up to date DOCTYPE declaration for your markup means not being able to use the entities which might be suggested below, when checking for applicable entities.

• Found empty <para> element in line 74.

Elements without any content make it impossible to translate the DocBook file into other languages; in particular, the xml2po program which is used by the KDE translation framework will break. You need to remove those elements, or fill them with some dummy content like "FILL ME WITH CONTENT" or such.

People who spent time on translating your document should be given credit appropriately. To do this, you need to specify two special comments in your markup:

<!-- TRANS:ROLES_OF_TRANSLATORS -->
This special comment must appear exactly once in your markup; you should put it at the end of your <authorgroup> element.

<!-- TRANS:CREDIT_FOR_TRANSLATORS -->
There must only be one DocBook file in the directory which has this marker. It needs to be placed at the end of your document, right before the &underFDL; entity.

• In line 84: Prefer '&eg;' over 'e.g.'. (Use the entity!)

  ..<listitem><para>Automatically place the type of the tranaction, e.g. Deposit, Withdrawl, etc., in the No. field.</para></listitem>..

• In line 99: Prefer '' over '&kappname;'. (Use the entity for this application instead)

  ..<listitem><para>When entering a new transaction with this option enabled, &kappname; will fill in all the transaction details based on the previous transaction with the selected payee.</para><para>For example, all your transactions to &quot;The &kappname; Development Team&quot; might be classified under the &quot;Contributions To Make The World a Better Place&quot; category. When you enter a new transaction and choose this payee, it will automatically pick this category.</para></listitem>..

• In line 181: Prefer 'email' over 'e-mail'.

  ..<listitem><para>Enter the e-mail address or the hexadecimal key id to use for data encryption.</para></listitem>..

• In line 194: Prefer '' over '&kappname;'. (Use the entity for this application instead)

  ..<listitem><para>Encrypts data with the &kappname; recover key, allowing core &kappname; developers to decrypt data in case you lose your encryption key.</para></listitem>..

For the sake of consistency (and proper spelling), there is a centralized list of common phrases and how they should be spelt in KDE manuals. This covers cases such as "file system" vs. "filesystem" or "Spell-check" vs. "Spellcheck". It's a matter of professional appearance, and you should really try to make your spelling consistent with that of the other KDE documents.

Not using the most up to date DOCTYPE declaration for your markup means not being able to use the entities which might be suggested below, when checking for applicable entities.

• Found empty <para> element in line 3.

Elements without any content make it impossible to translate the DocBook file into other languages; in particular, the xml2po program which is used by the KDE translation framework will break. You need to remove those elements, or fill them with some dummy content like "FILL ME WITH CONTENT" or such.

People who spent time on translating your document should be given credit appropriately. To do this, you need to specify two special comments in your markup:

<!-- TRANS:ROLES_OF_TRANSLATORS -->
This special comment must appear exactly once in your markup; you should put it at the end of your <authorgroup> element.

<!-- TRANS:CREDIT_FOR_TRANSLATORS -->
There must only be one DocBook file in the directory which has this marker. It needs to be placed at the end of your document, right before the &underFDL; entity.

People who spent time on translating your document should be given credit appropriately. To do this, you need to specify two special comments in your markup:

<!-- TRANS:ROLES_OF_TRANSLATORS -->
This special comment must appear exactly once in your markup; you should put it at the end of your <authorgroup> element.

<!-- TRANS:CREDIT_FOR_TRANSLATORS -->
There must only be one DocBook file in the directory which has this marker. It needs to be placed at the end of your document, right before the &underFDL; entity.

• In line 43: Prefer '' over '&kappname;'. (Use the entity for this application instead)

  ..<subtitle>for &kappname; version 0.9</subtitle>..

• In line 138: Prefer '' over '&kappname;'. (Use the entity for this application instead)

  ..This handbook describes &kappname; version 0.9...

For the sake of consistency (and proper spelling), there is a centralized list of common phrases and how they should be spelt in KDE manuals. This covers cases such as "file system" vs. "filesystem" or "Spell-check" vs. "Spellcheck". It's a matter of professional appearance, and you should really try to make your spelling consistent with that of the other KDE documents.

Note:It is not guaranteed that the document is still valid after applying these suggestions! If you happen to see a suggestion which would break the document, please send Frerich Raabe a mail about it.

• Entity could be used in line 135:

  -&kappname;, the personal finances manager for KDE.
  +&kappname;, the personal finances manager for &kde;.
  

There are a lot of entities available to authors of KDE manuals which make it easy to keep the spelling of applications and abbreviations consistent. Using them makes sure that application names are capitalized and marked up correctly, licensed terms get proper 'trademark' and 'copyright' signs, keys which are labelled differently in different countries (such as the 'Ctrl' key which is labelled 'Strg' on german keyboards) get automatically translated and more. To make a long story short - you don't lose anything when using entities as much as possible, but you gain a lot.

Not using the most up to date DOCTYPE declaration for your markup means not being able to use the entities which might be suggested below, when checking for applicable entities.

People who spent time on translating your document should be given credit appropriately. To do this, you need to specify two special comments in your markup:

<!-- TRANS:ROLES_OF_TRANSLATORS -->
This special comment must appear exactly once in your markup; you should put it at the end of your <authorgroup> element.

<!-- TRANS:CREDIT_FOR_TRANSLATORS -->
There must only be one DocBook file in the directory which has this marker. It needs to be placed at the end of your document, right before the &underFDL; entity.

Not using the most up to date DOCTYPE declaration for your markup means not being able to use the entities which might be suggested below, when checking for applicable entities.

People who spent time on translating your document should be given credit appropriately. To do this, you need to specify two special comments in your markup:

<!-- TRANS:ROLES_OF_TRANSLATORS -->
This special comment must appear exactly once in your markup; you should put it at the end of your <authorgroup> element.

<!-- TRANS:CREDIT_FOR_TRANSLATORS -->
There must only be one DocBook file in the directory which has this marker. It needs to be placed at the end of your document, right before the &underFDL; entity.

• In line 100: Prefer 'they are' over 'they're'.

  ..They are still listed in one of the other sections, but they're also aggregated here for your easy reference...

• In line 108: Prefer 'they are' over 'they're'.

  ..They are still listed in one of the other sections, but they're also aggregated here for your easy reference...

• In line 260: Prefer '' over '&kappname;'. (Use the entity for this application instead)

  ..If you're compiling &kappname; from source: first ensure that you have the KDChart libraries and headers; then configure with --enable-charts...

For the sake of consistency (and proper spelling), there is a centralized list of common phrases and how they should be spelt in KDE manuals. This covers cases such as "file system" vs. "filesystem" or "Spell-check" vs. "Spellcheck". It's a matter of professional appearance, and you should really try to make your spelling consistent with that of the other KDE documents.

Note:It is not guaranteed that the document is still valid after applying these suggestions! If you happen to see a suggestion which would break the document, please send Frerich Raabe a mail about it.

• Entity could be used in line 129:

  -	<listitem><para>Save:  Reports can be saved in HTML or CSV format.</para></listitem>
  +	<listitem><para>Save:  Reports can be saved in &HTML; or CSV format.</para></listitem>
  

There are a lot of entities available to authors of KDE manuals which make it easy to keep the spelling of applications and abbreviations consistent. Using them makes sure that application names are capitalized and marked up correctly, licensed terms get proper 'trademark' and 'copyright' signs, keys which are labelled differently in different countries (such as the 'Ctrl' key which is labelled 'Strg' on german keyboards) get automatically translated and more. To make a long story short - you don't lose anything when using entities as much as possible, but you gain a lot.

Not using the most up to date DOCTYPE declaration for your markup means not being able to use the entities which might be suggested below, when checking for applicable entities.

People who spent time on translating your document should be given credit appropriately. To do this, you need to specify two special comments in your markup:

<!-- TRANS:ROLES_OF_TRANSLATORS -->
This special comment must appear exactly once in your markup; you should put it at the end of your <authorgroup> element.

<!-- TRANS:CREDIT_FOR_TRANSLATORS -->
There must only be one DocBook file in the directory which has this marker. It needs to be placed at the end of your document, right before the &underFDL; entity.

• In line 29: Prefer '' over '&kappname;'. (Use the entity for this application instead)

  ..Only one &kappname; file can be open at once, so this will close your current file first...

• In line 289: Prefer 'Status bar' over 'Statusbar'.

  ..<guimenuitem>Hide/Show Statusbar </guimenuitem>..

• In line 291: Prefer 'status bar' over 'statusbar'.

  ..<listitem><para><action>Toggles bottom statusbar on or off.</action></para></listitem>..

• In line 353: Prefer '' over '&kappname;'. (Use the entity for this application instead)

  ..<listitem><para><action>Access the &kappname; Handbook.</action></para></listitem>..

• In line 388: Prefer '' over '&kappname;'. (Use the entity for this application instead)

  ..<listitem><para><action>Show About &kappname; information, including the version number and the credits.</action></para></listitem>..

For the sake of consistency (and proper spelling), there is a centralized list of common phrases and how they should be spelt in KDE manuals. This covers cases such as "file system" vs. "filesystem" or "Spell-check" vs. "Spellcheck". It's a matter of professional appearance, and you should really try to make your spelling consistent with that of the other KDE documents.

Note:It is not guaranteed that the document is still valid after applying these suggestions! If you happen to see a suggestion which would break the document, please send Frerich Raabe a mail about it.

• Entity could be used in line 396:

  -<listitem><para><action>Show KDE information.</action></para></listitem>
  +<listitem><para><action>Show &kde; information.</action></para></listitem>
  

There are a lot of entities available to authors of KDE manuals which make it easy to keep the spelling of applications and abbreviations consistent. Using them makes sure that application names are capitalized and marked up correctly, licensed terms get proper 'trademark' and 'copyright' signs, keys which are labelled differently in different countries (such as the 'Ctrl' key which is labelled 'Strg' on german keyboards) get automatically translated and more. To make a long story short - you don't lose anything when using entities as much as possible, but you gain a lot.

People who spent time on translating your document should be given credit appropriately. To do this, you need to specify two special comments in your markup:

<!-- TRANS:ROLES_OF_TRANSLATORS -->
This special comment must appear exactly once in your markup; you should put it at the end of your <authorgroup> element.

<!-- TRANS:CREDIT_FOR_TRANSLATORS -->
There must only be one DocBook file in the directory which has this marker. It needs to be placed at the end of your document, right before the &underFDL; entity.

Note:It is not guaranteed that the document is still valid after applying these suggestions! If you happen to see a suggestion which would break the document, please send Frerich Raabe a mail about it.

• Entity could be used in line 66:

  -document under the terms of the GNU Free Documentation License, Version 1.1
  +document under the terms of the &GNU; Free Documentation License, Version 1.1
  

• Entity could be used in line 70:

  -<link linkend="licence">"GNU Free Documentation License"</link>.
  +<link linkend="licence">"&GNU; Free Documentation License"</link>.
  

• Entity could be used in line 136:

  -<term>2005-09-18, Thomas Baumgart, Rev 1.0</term>
  +<term>2005-09-18, Thomas Baumgart, Rev &version;</term>
  

There are a lot of entities available to authors of KDE manuals which make it easy to keep the spelling of applications and abbreviations consistent. Using them makes sure that application names are capitalized and marked up correctly, licensed terms get proper 'trademark' and 'copyright' signs, keys which are labelled differently in different countries (such as the 'Ctrl' key which is labelled 'Strg' on german keyboards) get automatically translated and more. To make a long story short - you don't lose anything when using entities as much as possible, but you gain a lot.

Not using the most up to date DOCTYPE declaration for your markup means not being able to use the entities which might be suggested below, when checking for applicable entities.

People who spent time on translating your document should be given credit appropriately. To do this, you need to specify two special comments in your markup:

<!-- TRANS:ROLES_OF_TRANSLATORS -->
This special comment must appear exactly once in your markup; you should put it at the end of your <authorgroup> element.

<!-- TRANS:CREDIT_FOR_TRANSLATORS -->
There must only be one DocBook file in the directory which has this marker. It needs to be placed at the end of your document, right before the &underFDL; entity.

• In line 127: Prefer 'folders' over 'directories'. (Only use 'directory' for CLI)

  ..different directories on the same machine. This requires thorough attention..

For the sake of consistency (and proper spelling), there is a centralized list of common phrases and how they should be spelt in KDE manuals. This covers cases such as "file system" vs. "filesystem" or "Spell-check" vs. "Spellcheck". It's a matter of professional appearance, and you should really try to make your spelling consistent with that of the other KDE documents.

Not using the most up to date DOCTYPE declaration for your markup means not being able to use the entities which might be suggested below, when checking for applicable entities.

• Found empty <userinput> element in line 761.
• Found empty <userinput> element in line 789.

Elements without any content make it impossible to translate the DocBook file into other languages; in particular, the xml2po program which is used by the KDE translation framework will break. You need to remove those elements, or fill them with some dummy content like "FILL ME WITH CONTENT" or such.

People who spent time on translating your document should be given credit appropriately. To do this, you need to specify two special comments in your markup:

<!-- TRANS:ROLES_OF_TRANSLATORS -->
This special comment must appear exactly once in your markup; you should put it at the end of your <authorgroup> element.

<!-- TRANS:CREDIT_FOR_TRANSLATORS -->
There must only be one DocBook file in the directory which has this marker. It needs to be placed at the end of your document, right before the &underFDL; entity.

• In line 49: Prefer 'folder' over 'directory'. (Only use 'directory' for CLI)

  ..<para>Create a new directory for this release..

• In line 52: Prefer 'folder' over 'directory'. (Only use 'directory' for CLI)

  ..Create a new directory specifically for the release process, something like /home/me/distkmm, which will ensure that the following steps are not contaminated by other, existing versions of &app;. From this directory, check out a copy of the app from the CVS branch which forms the basis of this release, e.g. for 0.8.2, the branch will be rel-0-8-branch. The checkout process will create a sub-directory called kmymoney2. This is referred to subsequently as the TLD (top level directory)...

• In line 52: Prefer '&eg;' over 'e.g.'. (Use the entity!)

  ..Create a new directory specifically for the release process, something like /home/me/distkmm, which will ensure that the following steps are not contaminated by other, existing versions of &app;. From this directory, check out a copy of the app from the CVS branch which forms the basis of this release, e.g. for 0.8.2, the branch will be rel-0-8-branch. The checkout process will create a sub-directory called kmymoney2. This is referred to subsequently as the TLD (top level directory)...

• In line 257: Prefer 'Folder' over 'Directory'. (Only use 'directory' for CLI)

  ..250 Directory successfully changed...

• In line 336: Prefer '&eg;' over 'e.g.'. (Use the entity!)

  ..<para>After a follow-up release, increase the micro-release-number by one, e.g. if the release you are currently working on is called 0.7.3 then set the release number to 0.7.4. </para>..

• In line 589: Prefer 'folder' over 'directory'. (Only use 'directory' for CLI)

  ..The RPM system uses a directory structure which..

• In line 593: Prefer 'folder' over 'directory'. (Only use 'directory' for CLI)

  ..I will refer to this directory as the 'RPM base directory' in the remainder..

• In line 598: Prefer 'folder' over 'directory'. (Only use 'directory' for CLI)

  ..The RPM base directory has a set of subdirectories. They all serve a..

• In line 599: Prefer 'folders' over 'directories'. (Only use 'directory' for CLI)

  ..specific purpose. For us, the directories SOURCES, SPECS, SRPMS and RPMS..

• In line 600: Prefer 'folders' over 'directories'. (Only use 'directory' for CLI)

  ..are important. RPMS is further divided into directories for specific..

• In line 602: Prefer 'folders' over 'directories'. (Only use 'directory' for CLI)

  ..document, I will use the names of these directories without mentioning..

• In line 623: Prefer 'folder' over 'directory'. (Only use 'directory' for CLI)

  ..the directory name to $NAME.orig. Then unpack the source again. Use..

• In line 624: Prefer 'folder' over 'directory'. (Only use 'directory' for CLI)

  ..this source to build from. Go into the source directory and follow the..

• In line 628: Prefer 'folder' over 'directory'. (Only use 'directory' for CLI)

  ..back out of the source directory to its parent. Then you'll do..

For the sake of consistency (and proper spelling), there is a centralized list of common phrases and how they should be spelt in KDE manuals. This covers cases such as "file system" vs. "filesystem" or "Spell-check" vs. "Spellcheck". It's a matter of professional appearance, and you should really try to make your spelling consistent with that of the other KDE documents.

Note:It is not guaranteed that the document is still valid after applying these suggestions! If you happen to see a suggestion which would break the document, please send Frerich Raabe a mail about it.

• Entity could be used in line 240:

  -For GUI users: <emphasis>anonymous</emphasis> is the user-name and
  +For &GUI; users: <emphasis>anonymous</emphasis> is the user-name and
  

• Entity could be used in line 244:

  -For command line FTP, from the TLD:
  +For command line &FTP;, from the TLD:
  

• Entity could be used in line 254:

  -Remote system type is UNIX.
  +Remote system type is &UNIX;.
  

• Entity could be used in line 273:

  -To do that, load the following URL in your browser
  +To do that, load the following &URL; in your browser
  

• Entity could be used in line 310:

  -<para>If the ChangeLog indicates that any Sourceforge or KDE bugs have been fixed in this release, log on to the respective bug sites and ensure that they are marked as closed.
  +<para>If the ChangeLog indicates that any Sourceforge or &kde; bugs have been fixed in this release, log on to the respective bug sites and ensure that they are marked as closed.
  

• Entity could be used in line 572:

  -Multiple formats exist: RPM, DEB, e-builds, PKG just to name a few. Since the distro I use (SuSE) relies on
  +Multiple formats exist: RPM, DEB, e-builds, PKG just to name a few. Since the distro I use (&SuSE;) relies on
  

• Entity could be used in line 590:

  -for my system - a SuSE distribution - is located in /usr/src/packages. This
  +for my system - a &SuSE; distribution - is located in /usr/src/packages. This
  

• Entity could be used in line 659:

  -It will work on SuSE 8.1 directly. More details on howto setup a SPEC file
  +It will work on &SuSE; 8.1 directly. More details on howto setup a SPEC file
  

There are a lot of entities available to authors of KDE manuals which make it easy to keep the spelling of applications and abbreviations consistent. Using them makes sure that application names are capitalized and marked up correctly, licensed terms get proper 'trademark' and 'copyright' signs, keys which are labelled differently in different countries (such as the 'Ctrl' key which is labelled 'Strg' on german keyboards) get automatically translated and more. To make a long story short - you don't lose anything when using entities as much as possible, but you gain a lot.

Not using the most up to date DOCTYPE declaration for your markup means not being able to use the entities which might be suggested below, when checking for applicable entities.

People who spent time on translating your document should be given credit appropriately. To do this, you need to specify two special comments in your markup:

<!-- TRANS:ROLES_OF_TRANSLATORS -->
This special comment must appear exactly once in your markup; you should put it at the end of your <authorgroup> element.

<!-- TRANS:CREDIT_FOR_TRANSLATORS -->
There must only be one DocBook file in the directory which has this marker. It needs to be placed at the end of your document, right before the &underFDL; entity.

• In line 28: Prefer '&eg;' over 'e.g.'. (Use the entity!)

  ..<command>#<emphasis>assigned-number</emphasis></command>, e.g. #481229...

For the sake of consistency (and proper spelling), there is a centralized list of common phrases and how they should be spelt in KDE manuals. This covers cases such as "file system" vs. "filesystem" or "Spell-check" vs. "Spellcheck". It's a matter of professional appearance, and you should really try to make your spelling consistent with that of the other KDE documents.

Not using the most up to date DOCTYPE declaration for your markup means not being able to use the entities which might be suggested below, when checking for applicable entities.

Just like elements without any content, multiple root elements make it impossible to translate the DocBook file into other languages. You should split a file with multiple root elements up into a bunch of files with one root element each.

People who spent time on translating your document should be given credit appropriately. To do this, you need to specify two special comments in your markup:

<!-- TRANS:ROLES_OF_TRANSLATORS -->
This special comment must appear exactly once in your markup; you should put it at the end of your <authorgroup> element.

<!-- TRANS:CREDIT_FOR_TRANSLATORS -->
There must only be one DocBook file in the directory which has this marker. It needs to be placed at the end of your document, right before the &underFDL; entity.

• In line 34: Prefer '&eg;' over 'e.g.'. (Use the entity!)

  ..The po file contains the English and the translated text, e.g. German...

• In line 35: Prefer 'cannot' over 'can't'.

  ..There might be two cases: The first case you can't find a po file for your..

• In line 69: Prefer '&eg;' over 'e.g.'. (Use the entity!)

  ..is your language code e.g. <emphasis>de</emphasis> for German...

• In line 82: Prefer '&ie;' over 'i.e.'. (Use the entity!)

  ..the case, i.e. your po file has all the latest English text inside, you can..

• In line 191: Prefer 'cannot' over 'can't'.

  ..text. If you can't find the file on your harddrive try either..

For the sake of consistency (and proper spelling), there is a centralized list of common phrases and how they should be spelt in KDE manuals. This covers cases such as "file system" vs. "filesystem" or "Spell-check" vs. "Spellcheck". It's a matter of professional appearance, and you should really try to make your spelling consistent with that of the other KDE documents.

Note:It is not guaranteed that the document is still valid after applying these suggestions! If you happen to see a suggestion which would break the document, please send Frerich Raabe a mail about it.

• Entity could be used in line 17:

  -This chapter should give any one (in particular people who are not developers) a first overview on how they can translate &app; into another language. The information given here is not only valid for &app; but as serves for the translation of any KDE project.
  +This chapter should give any one (in particular people who are not developers) a first overview on how they can translate &app; into another language. The information given here is not only valid for &app; but as serves for the translation of any &kde; project.
  

• Entity could be used in line 186:

  -distro, for SuSE it is <filename>/opt/kde3/share/local/lang/LC_MESSAGES</filename> and for Debian
  +distro, for &SuSE; it is <filename>/opt/kde3/share/local/lang/LC_MESSAGES</filename> and for Debian
  

• Entity could be used in line 189:

  -language. Be aware that &app; uses some text strings from KDE and since they
  +language. Be aware that &app; uses some text strings from &kde; and since they
  

• Entity could be used in line 210:

  -In order to run &app; either start it as usual (if your default KDE language
  +In order to run &app; either start it as usual (if your default &kde; language
  

There are a lot of entities available to authors of KDE manuals which make it easy to keep the spelling of applications and abbreviations consistent. Using them makes sure that application names are capitalized and marked up correctly, licensed terms get proper 'trademark' and 'copyright' signs, keys which are labelled differently in different countries (such as the 'Ctrl' key which is labelled 'Strg' on german keyboards) get automatically translated and more. To make a long story short - you don't lose anything when using entities as much as possible, but you gain a lot.

Not using the most up to date DOCTYPE declaration for your markup means not being able to use the entities which might be suggested below, when checking for applicable entities.

People who spent time on translating your document should be given credit appropriately. To do this, you need to specify two special comments in your markup:

<!-- TRANS:ROLES_OF_TRANSLATORS -->
This special comment must appear exactly once in your markup; you should put it at the end of your <authorgroup> element.

<!-- TRANS:CREDIT_FOR_TRANSLATORS -->
There must only be one DocBook file in the directory which has this marker. It needs to be placed at the end of your document, right before the &underFDL; entity.

• In line 4: Prefer '' over '&kappname;'. (Use the entity for this application instead)

  ..<para>This section is a developer's guide explaining the peculiarities of dialog creation in &kappname;. A basic understanding of Qt GUI programming is assumed, as is a knowledge of &kappname; coding standards as laid out in the Project Handbook.</para>..

• In line 9: Prefer '' over '&kappname;'. (Use the entity for this application instead)

  ..<para>The default language of &kappname; is American English, but don't let that put you off! All contributions will be welcome, and as long as you have a basic knowledge of the language, the members of the &kappname; developers list will be happy to help you polish it up.</para>..

• In line 15: Prefer 'lowercase' over 'lower case'.

  ..<para>First step is to choose a meaningful name for your dialog (and preferably one that's not already in use! - see the kmymoney2/dialogs source directory). In accordance with &kappname; coding conventions, the name should consist of 2 or 3 (or more) 'words', strung together without spaces. To keep names to a manageable length, these 'words' may be abbreviated, e.g. 'sched' for 'schedule'. Each 'word' should be spelt with an initial upper-case letter. Also, the names of dialogs are always preceded by a letter 'K', thus e.g. KEditSchedTrans. This name will be indicated in the rest of this chapter by &lt;KN&gt;. There are nevertheless occasions where all lower case letters are appropriate, specifically source file names; this will be indicated as &lt;kn&gt;.</para>..

• In line 15: Prefer 'uppercase' over 'upper-case'.

  ..<para>First step is to choose a meaningful name for your dialog (and preferably one that's not already in use! - see the kmymoney2/dialogs source directory). In accordance with &kappname; coding conventions, the name should consist of 2 or 3 (or more) 'words', strung together without spaces. To keep names to a manageable length, these 'words' may be abbreviated, e.g. 'sched' for 'schedule'. Each 'word' should be spelt with an initial upper-case letter. Also, the names of dialogs are always preceded by a letter 'K', thus e.g. KEditSchedTrans. This name will be indicated in the rest of this chapter by &lt;KN&gt;. There are nevertheless occasions where all lower case letters are appropriate, specifically source file names; this will be indicated as &lt;kn&gt;.</para>..

• In line 15: Prefer '&eg;' over 'e.g.'. (Use the entity!)

  ..<para>First step is to choose a meaningful name for your dialog (and preferably one that's not already in use! - see the kmymoney2/dialogs source directory). In accordance with &kappname; coding conventions, the name should consist of 2 or 3 (or more) 'words', strung together without spaces. To keep names to a manageable length, these 'words' may be abbreviated, e.g. 'sched' for 'schedule'. Each 'word' should be spelt with an initial upper-case letter. Also, the names of dialogs are always preceded by a letter 'K', thus e.g. KEditSchedTrans. This name will be indicated in the rest of this chapter by &lt;KN&gt;. There are nevertheless occasions where all lower case letters are appropriate, specifically source file names; this will be indicated as &lt;kn&gt;.</para>..

• In line 15: Prefer '' over '&kappname;'. (Use the entity for this application instead)

  ..<para>First step is to choose a meaningful name for your dialog (and preferably one that's not already in use! - see the kmymoney2/dialogs source directory). In accordance with &kappname; coding conventions, the name should consist of 2 or 3 (or more) 'words', strung together without spaces. To keep names to a manageable length, these 'words' may be abbreviated, e.g. 'sched' for 'schedule'. Each 'word' should be spelt with an initial upper-case letter. Also, the names of dialogs are always preceded by a letter 'K', thus e.g. KEditSchedTrans. This name will be indicated in the rest of this chapter by &lt;KN&gt;. There are nevertheless occasions where all lower case letters are appropriate, specifically source file names; this will be indicated as &lt;kn&gt;.</para>..

• In line 30: Prefer '&eg;' over 'e.g.'. (Use the entity!)

  ..<para>Fixed widgets, e.g. text labels, can often use the default names assigned by Designer. Other widgets on your form should be given names which are meaningful in an application context. This is particularly important for those widgets which are to be referenced in code. As per the application programming standards, these names should be prefixed with 'm_' to indicate them as member variables of the dialog.</para>..

For the sake of consistency (and proper spelling), there is a centralized list of common phrases and how they should be spelt in KDE manuals. This covers cases such as "file system" vs. "filesystem" or "Spell-check" vs. "Spellcheck". It's a matter of professional appearance, and you should really try to make your spelling consistent with that of the other KDE documents.

Note:It is not guaranteed that the document is still valid after applying these suggestions! If you happen to see a suggestion which would break the document, please send Frerich Raabe a mail about it.

• Entity could be used in line 4:

  -    <para>This section is a developer's guide explaining the peculiarities of dialog creation in &kappname;. A basic understanding of Qt GUI programming is assumed, as is a knowledge of &kappname; coding standards as laid out in the Project Handbook.</para>
  +    <para>This section is a developer's guide explaining the peculiarities of dialog creation in &kappname;. A basic understanding of &Qt; &GUI; programming is assumed, as is a knowledge of &kappname; coding standards as laid out in the Project Handbook.</para>
  

• Entity could be used in line 21:

  -      <para>The dialog screen should be built using Qt Designer. This section assumes that you are using version 3.x of Qt. Version 4 is, at present, an unknown quantity.</para>
  +      <para>The dialog screen should be built using &Qt; Designer. This section assumes that you are using version 3.x of &Qt;. Version 4 is, at present, an unknown quantity.</para>
  

• Entity could be used in line 38:

  -        <para>Fixed text fields and labels in the form do not require any special consideration. Qt Designer and the project's build environment will take care of wrapping the strings into an i18n construct for presentation to translators.</para>
  +        <para>Fixed text fields and labels in the form do not require any special consideration. &Qt; Designer and the project's build environment will take care of wrapping the strings into an i18n construct for presentation to translators.</para>
  

• Entity could be used in line 75:

  -        <para>The include file will have been generated by the Qt UIC (User Interface Compiler) from the .ui file for the dialog, under control of the make process.</para>
  +        <para>The include file will have been generated by the &Qt; UIC (User Interface Compiler) from the .ui file for the dialog, under control of the make process.</para>
  

• Entity could be used in line 77:

  -        <para>The Q_OBJECT macro (written without any punctuation) will cause the Qt MOC (Meta Object Compiler) to generate additional object code and files which are necessary to support the signal/slot functionality (among other things).</para>
  +        <para>The Q_OBJECT macro (written without any punctuation) will cause the &Qt; MOC (Meta Object Compiler) to generate additional object code and files which are necessary to support the signal/slot functionality (among other things).</para>
  

• Entity could be used in line 88:

  -        <para>sections if you plan to use the signal/slot mechanism. See the Qt documentation about signals and slots. An example would be slotHelp() which will be connected to the clicked() signal of the help button of your dialog in the constructor of your dialog.</para>
  +        <para>sections if you plan to use the signal/slot mechanism. See the &Qt; documentation about signals and slots. An example would be slotHelp() which will be connected to the clicked() signal of the help button of your dialog in the constructor of your dialog.</para>
  

• Entity could be used in line 100:

  -        <para>First, don't forget to have #include directives for Qt headers for any widgets you are going to reference.</para>
  +        <para>First, don't forget to have #include directives for &Qt; headers for any widgets you are going to reference.</para>
  

• Entity could be used in line 102:

  -        <para>In the constructor function, connect all signals to their appropriate slots using the Qt connect() call.</para>
  +        <para>In the constructor function, connect all signals to their appropriate slots using the &Qt; connect() call.</para>
  

• Entity could be used in line 110:

  -        <para>This is one of the files generated by the Qt MOC (Meta Object Compiler) during the make process; if you finish up with 'vtable' errors, it's probably because you forgot to include this.</para>
  +        <para>This is one of the files generated by the &Qt; MOC (Meta Object Compiler) during the make process; if you finish up with 'vtable' errors, it's probably because you forgot to include this.</para>
  

There are a lot of entities available to authors of KDE manuals which make it easy to keep the spelling of applications and abbreviations consistent. Using them makes sure that application names are capitalized and marked up correctly, licensed terms get proper 'trademark' and 'copyright' signs, keys which are labelled differently in different countries (such as the 'Ctrl' key which is labelled 'Strg' on german keyboards) get automatically translated and more. To make a long story short - you don't lose anything when using entities as much as possible, but you gain a lot.

Not using the most up to date DOCTYPE declaration for your markup means not being able to use the entities which might be suggested below, when checking for applicable entities.

People who spent time on translating your document should be given credit appropriately. To do this, you need to specify two special comments in your markup:

<!-- TRANS:ROLES_OF_TRANSLATORS -->
This special comment must appear exactly once in your markup; you should put it at the end of your <authorgroup> element.

<!-- TRANS:CREDIT_FOR_TRANSLATORS -->
There must only be one DocBook file in the directory which has this marker. It needs to be placed at the end of your document, right before the &underFDL; entity.

• In line 252: Prefer 'lowercase' over 'lower case'.

  ..method should start with a lower case letter with each subsequent word..

• In line 253: Prefer 'uppercase' over 'upper case'.

  ..having an upper case start letter...

For the sake of consistency (and proper spelling), there is a centralized list of common phrases and how they should be spelt in KDE manuals. This covers cases such as "file system" vs. "filesystem" or "Spell-check" vs. "Spellcheck". It's a matter of professional appearance, and you should really try to make your spelling consistent with that of the other KDE documents.

Note:It is not guaranteed that the document is still valid after applying these suggestions! If you happen to see a suggestion which would break the document, please send Frerich Raabe a mail about it.

• Entity could be used in line 34:

  -tabs should be changed into spaces. (KDevelop/KWrite supports tab
  +tabs should be changed into spaces. (KDevelop/&kwrite; supports tab
  

• Entity could be used in line 110:

  -All classes designed for use by the KDE interface should begin with a
  +All classes designed for use by the &kde; interface should begin with a
  

There are a lot of entities available to authors of KDE manuals which make it easy to keep the spelling of applications and abbreviations consistent. Using them makes sure that application names are capitalized and marked up correctly, licensed terms get proper 'trademark' and 'copyright' signs, keys which are labelled differently in different countries (such as the 'Ctrl' key which is labelled 'Strg' on german keyboards) get automatically translated and more. To make a long story short - you don't lose anything when using entities as much as possible, but you gain a lot.

Not using the most up to date DOCTYPE declaration for your markup means not being able to use the entities which might be suggested below, when checking for applicable entities.

Just like elements without any content, multiple root elements make it impossible to translate the DocBook file into other languages. You should split a file with multiple root elements up into a bunch of files with one root element each.

People who spent time on translating your document should be given credit appropriately. To do this, you need to specify two special comments in your markup:

<!-- TRANS:ROLES_OF_TRANSLATORS -->
This special comment must appear exactly once in your markup; you should put it at the end of your <authorgroup> element.

<!-- TRANS:CREDIT_FOR_TRANSLATORS -->
There must only be one DocBook file in the directory which has this marker. It needs to be placed at the end of your document, right before the &underFDL; entity.

• In line 323: Prefer '&ie;' over 'i.e.'. (Use the entity!)

  ..through a test case should be removed by tearDown(), i.e. the environment..

For the sake of consistency (and proper spelling), there is a centralized list of common phrases and how they should be spelt in KDE manuals. This covers cases such as "file system" vs. "filesystem" or "Spell-check" vs. "Spellcheck". It's a matter of professional appearance, and you should really try to make your spelling consistent with that of the other KDE documents.

Note:It is not guaranteed that the document is still valid after applying these suggestions! If you happen to see a suggestion which would break the document, please send Frerich Raabe a mail about it.

• Entity could be used in line 91:

  -hard to achieve (e.g. for GUI related code) but I found, that whenever it
  +hard to achieve (e.g. for &GUI; related code) but I found, that whenever it
  

• Entity could be used in line 115:

  -in such a way, that it is not based on any KDE code which the old one was.
  -The second goal to free it from Qt based code was not that easy and was
  +in such a way, that it is not based on any &kde; code which the old one was.
  +The second goal to free it from &Qt; based code was not that easy and was
  

There are a lot of entities available to authors of KDE manuals which make it easy to keep the spelling of applications and abbreviations consistent. Using them makes sure that application names are capitalized and marked up correctly, licensed terms get proper 'trademark' and 'copyright' signs, keys which are labelled differently in different countries (such as the 'Ctrl' key which is labelled 'Strg' on german keyboards) get automatically translated and more. To make a long story short - you don't lose anything when using entities as much as possible, but you gain a lot.

Not using the most up to date DOCTYPE declaration for your markup means not being able to use the entities which might be suggested below, when checking for applicable entities.

People who spent time on translating your document should be given credit appropriately. To do this, you need to specify two special comments in your markup:

<!-- TRANS:ROLES_OF_TRANSLATORS -->
This special comment must appear exactly once in your markup; you should put it at the end of your <authorgroup> element.

<!-- TRANS:CREDIT_FOR_TRANSLATORS -->
There must only be one DocBook file in the directory which has this marker. It needs to be placed at the end of your document, right before the &underFDL; entity.

• In line 259: Prefer 'folders' over 'directories'. (Only use 'directory' for CLI)

  ..- Remove CVS directories from SRPMS..

For the sake of consistency (and proper spelling), there is a centralized list of common phrases and how they should be spelt in KDE manuals. This covers cases such as "file system" vs. "filesystem" or "Spell-check" vs. "Spellcheck". It's a matter of professional appearance, and you should really try to make your spelling consistent with that of the other KDE documents.

Not using the most up to date DOCTYPE declaration for your markup means not being able to use the entities which might be suggested below, when checking for applicable entities.

People who spent time on translating your document should be given credit appropriately. To do this, you need to specify two special comments in your markup:

<!-- TRANS:ROLES_OF_TRANSLATORS -->
This special comment must appear exactly once in your markup; you should put it at the end of your <authorgroup> element.

<!-- TRANS:CREDIT_FOR_TRANSLATORS -->
There must only be one DocBook file in the directory which has this marker. It needs to be placed at the end of your document, right before the &underFDL; entity.

Not using the most up to date DOCTYPE declaration for your markup means not being able to use the entities which might be suggested below, when checking for applicable entities.

People who spent time on translating your document should be given credit appropriately. To do this, you need to specify two special comments in your markup:

<!-- TRANS:ROLES_OF_TRANSLATORS -->
This special comment must appear exactly once in your markup; you should put it at the end of your <authorgroup> element.

<!-- TRANS:CREDIT_FOR_TRANSLATORS -->
There must only be one DocBook file in the directory which has this marker. It needs to be placed at the end of your document, right before the &underFDL; entity.

Not using the most up to date DOCTYPE declaration for your markup means not being able to use the entities which might be suggested below, when checking for applicable entities.

People who spent time on translating your document should be given credit appropriately. To do this, you need to specify two special comments in your markup:

<!-- TRANS:ROLES_OF_TRANSLATORS -->
This special comment must appear exactly once in your markup; you should put it at the end of your <authorgroup> element.

<!-- TRANS:CREDIT_FOR_TRANSLATORS -->
There must only be one DocBook file in the directory which has this marker. It needs to be placed at the end of your document, right before the &underFDL; entity.

Not using the most up to date DOCTYPE declaration for your markup means not being able to use the entities which might be suggested below, when checking for applicable entities.

People who spent time on translating your document should be given credit appropriately. To do this, you need to specify two special comments in your markup:

<!-- TRANS:ROLES_OF_TRANSLATORS -->
This special comment must appear exactly once in your markup; you should put it at the end of your <authorgroup> element.

<!-- TRANS:CREDIT_FOR_TRANSLATORS -->
There must only be one DocBook file in the directory which has this marker. It needs to be placed at the end of your document, right before the &underFDL; entity.

• In line 55: Prefer 'folder' over 'directory'. (Only use 'directory' for CLI)

  ..For the &app; project, a directory named <command>kmymoney2</command> is..

• In line 100: Prefer 'folder' over 'directory'. (Only use 'directory' for CLI)

  ..As in the previous example, the directory kmymoney2 is created as the..

• In line 308: Prefer 'folder' over 'directory'. (Only use 'directory' for CLI)

  ..In directory usw-pr-cvs1:/tmp/cvs-serv6662..

• In line 345: Prefer 'folder' over 'directory'. (Only use 'directory' for CLI)

  ..&cvs; commands, it operates recursively from the current working directory in..

• In line 501: Prefer 'folders' over 'directories'. (Only use 'directory' for CLI)

  ..important to move all the CVS directories as well. If you start from..

• In line 553: Prefer 'folder' over 'directory'. (Only use 'directory' for CLI)

  ..machine, you can add the version number to the stable directory (e.g...

• In line 640: Prefer 'folder' over 'directory'. (Only use 'directory' for CLI)

  ..development directory tree by merely re-typing it...

For the sake of consistency (and proper spelling), there is a centralized list of common phrases and how they should be spelt in KDE manuals. This covers cases such as "file system" vs. "filesystem" or "Spell-check" vs. "Spellcheck". It's a matter of professional appearance, and you should really try to make your spelling consistent with that of the other KDE documents.

Note:It is not guaranteed that the document is still valid after applying these suggestions! If you happen to see a suggestion which would break the document, please send Frerich Raabe a mail about it.

• Entity could be used in line 20:

  -accessible through various GUI clients available for &cvs;.  Also, I usually
  +accessible through various &GUI; clients available for &cvs;.  Also, I usually
  

There are a lot of entities available to authors of KDE manuals which make it easy to keep the spelling of applications and abbreviations consistent. Using them makes sure that application names are capitalized and marked up correctly, licensed terms get proper 'trademark' and 'copyright' signs, keys which are labelled differently in different countries (such as the 'Ctrl' key which is labelled 'Strg' on german keyboards) get automatically translated and more. To make a long story short - you don't lose anything when using entities as much as possible, but you gain a lot.