OpenLLM-France/wikimedia huggingface dataset:
# Copying Content

Back to the Top
* Trainz Asset Maintenance and Creation Content Manager skills tutorials for Trainz
* TOC | Beginnings | Fun | AM&C | Creation | InBook Refs | ORP Refs:  • Index • Containers • Kinds • Tags | Appendixes  • Vers
Glossary :
HKeys-CM :
HKeys-DVR :
HKeys-SUR :
HKeys-WIN :
Mouse use :
Notations :

## Introduction

This section is concerned with copying assets, i.e. Trainz data files.
All copying of assets is potentially subject to copyright considerations but this chapter does not address that issue. Nor does it address the uploading of content so as to make it available to the general public on Auran's DLS system or a third-party Trainz fansite. Uploading is covered in a separate chapter of this book.
You may wish to copy assets in situations such as the following:
* You are upgrading to a new computer.
* You have two or more different versions of Trainz installed on the same computer.
* You have copies of Trainz installed on two or more computers.
* You wish to exchange assets with a small number of friends.

## Copying Post-Installation Files
### TRS2004 to TRS2004 - downloaded assets

    Copy the relevant KUID folders in the C:\Program Files\Auran\TRS2004\World\Dispatcher\Downloads folder to the corresponding place on the destination computer. Then manually delete the C:\Program Files\Auran\TRS2004\Cache\world_cache_Dispatcher.chump file. It will usually be appropriate to only copy the top-level assets and then use the free third-party Trainz Objectz asset management program to list any missing dependencies.

### TRS2004 to TRS2004 - self-created assets

    Either copy the relevant folders in the C:\Program Files\Auran\TRS2004\World\Custom folder to the corresponding place on the destination computer and then manually delete the C:\Program Files\Auran\TRS2004\Cache\world_cache_Dispatcher.chump file, or (and much more preferably) use the Content Dispatcher sub-program supplied with Trainz to convert them to CDP files, which can then be installed on the recipient's computer as if they had been downloaded.

### TRS2004 to TRS2006, to TC, to all other versions

    best done via importing into other versions in a daisy chain, dealing with errors, then importing to the next higher version.

### TRS2006 to TRS2006

    (not yet written)

### TRS2006 to TC

    (not yet written; needs to include instructions for transferring those built-in assets which TC lacks)

### Any transfers from later versions to earlier versions (eg TRS2006 to TRS2004)

    (not yet written; is this needed?)
| Previous page: | ↑ Trainz | Next page: |
| | ⇐ Previous Glossary  Next ⇒ | [ references ] → |
# Trainz/Creating Coaches

kuid <kuid:895695:98433331> username "IR LHB DECCAN QUEEN AC CHAIR CAR " trainz-build 3.1 category-class "AA" category-region "INDIA" category-era "2010s" kind "traincar" engine 0 nightmode "lamp" enginespec <kuid2:9:50014:1> mass 37000 author "FaXcY Gaming " interior <kuid:895695:289501>
mesh-table {
bogeys {
kuid-table {
# Trainz/Content Creators

Trainz/refs/TrainzBaseSpec
# Trainz/Content Manager Tips

Back to the Top
* Trainz Asset Maintenance and Creation Content Manager skills tutorials for Trainz
* TOC | Beginnings | Fun | AM&C | Creation | InBook Refs | ORP Refs:  • Index • Containers • Kinds • Tags | Appendixes  • Vers
Glossary :
HKeys-CM :
HKeys-DVR :
HKeys-SUR :
HKeys-WIN :
Mouse use :
Notations :

## Introduction

Running Content Manager can sometimes be frustrating given the kludgy nature of the user interface. The worst problems occur after downloading a route which suddenly bequeaths a variety of faulty content items, with some of that missing other dependencies, and so instead of playing, you have to track what is going on. Perhaps you do as I do and keep a log file or spreadsheet of downloads.

## Adding kuids to a list

Adding kuids to a Search list you want to keep static requires a trick--a double use of a kuid list.

### Consider this common scenario

* Assume you keep a log file of downloads by version, or put that up in a spreadsheet
* Assume the aftermath of a download—you want the main view list captured and put into a text file anyway, so do that or paste them into an Open Office (Calc) spreadsheet.
* Assume further, the download was a route, and the dependencies, all of them new to you ran to the hundreds.
* You've got 8-12 new faulty assets, scattered through that big list in the main view
* and further, you run more than one Trainz, so you need to track fixed assets so you can output CDP's for the one's you fix. (Elsewhere in AM&C you were advised, if your ISP speed is high enough to separately download assets instead of copying or exporting cdp files across versions. We repeat that advice here!--Fabartus)
* If you are just focused on faulty assets, your initial list is too long and unweildy, so after selecting the download by 'View in Main List' you set an auxiliary filter Faulty+True, so now you can see just the errors.
# Wikimedia/Basic Markup Language

MediaWiki's markup system may sound daunting and complex at first glance, but it's not nearly as hard as it seems! First, let's start with "bold", all you do is wrap the text you want to be bold in '''. For example: if I wanted to make the word "Cat" bold, I would type '''Cat'''. It would produce this result: Cat. To put text in italics, you'd do the same but in two ''s. Example: ''cat'' would produce the result cat.
Next, linking. To link to another article, you would wrap the article name in square brackets. For example, to link to the page History, you would type [[History]]. That would produce the result History. To link to an external link, you would set it out like this [URL Text]. For example, if one types [http://www.google.co.uk Google], the system would produce the result Google. It's that simple.
The next important thing is templates. To transclude a template, one would type (let's take the template Lorem ipsum for example) {{Lorem ipsum}}. However, some templates require that you determine variables. To determine variable X on template Y one would type {{X|Y=Test}}. This is especially useful in infoboxes that rely on the information you enter. To substitute a template for its code (only recommended for warnings, and similar circumstances), you simply add the subst: prefix. Finally, categorisation. To add a page to a category you simply type [[Category:Category name]]. This code would add the page to category Category name.
That's it for the basics of Wikipedia markup!
# Wikimedia/Categories

Categories are a vital part of all wikis, especially Wikipedia. They allow users to sort pages into groups, to allow easy and comfortable navigation. To add a page to a category, one would need to link the category at the bottom of the page. Using the example of "fruit", one would write [[Category:Fruit]] at the bottom of the page to add the page to the category "Fruit".

## Usage in templates

Templates can add categories automatically, especially if that is their function (for example: stubs). This is done by adding a category to the template. If the user does not want the template to be added to the category, they would write (let's use the example: Baseball players this time) <includeonly>[[Category:Baseball players]]</includeonly> at the bottom of the template's code. This will make sure, when the template is used, that only pages that transclude (use) the template will be added to that category.
# Wikimedia/Editing

Wikimedia projects use the wikitext markup language which is easy to learn. Edits are subject to modification or deletion by other editors. Each edit provides a comment line which aggregates to a separate page. This comment line typically provides an opportunity to provide a brief characterization or justification of the edit.
# Wikimedia/Administrators

Most Wikimedia wikis have a group of trusted users called administrators (or sysops). They are normally appointed following a community discussion were users present arguments in favour and arguments against appointing the user. These discussions typically last a week. These discussions are closed by bureaucrats, a higher role in the community (as the administrator right can only be granted by bureaucrats and staff). Once the right is granted, the user will receive advanced rights, including the right to delete pages, protect pages, view/edit abusefilters, block users and grant and revoke basic rights such as reviewer, rollback and patroller.

## Bureaucrats

Bureaucrats are administrators that have access to several higher functions. Until recently, bureaucrats could locally rename users. This right was revoked in favour of Global Renamers. Now only Stewards and Global Renamers can rename users. Now, a bureaucrat's core right is to grant and revoke the administrator right, and grant the bureaucrat right. They cannot make users CheckUsers or Oversighters, however, that has to be done by stewards.

## Oversighters

Oversighters have the ability to hide revisions from both the public's view, and the view of regular administrators. This only occurs in special cases, however, such as personal information being given on a userpage. Other cases are normally handled by normal administrators. As this involves handling personal information, Wikimedia requires proof that the user is at least 18 years old.

## CheckUsers

CheckUsers have the ability to "check" a user. This consists of two functions: Listing all IPs used by a user, and listing all users used by an IP. This is essential when administrators are investigating cases of sockpuppetry. As this involves handling personal information, Wikimedia requires proof that the user is at least 18 years old.

## New wikis

New wikis (ones that have just been exported from The Incubator) generally don't have local administrators. Normally, it's preferable if an administrator is appointed as soon as possible via community discussion. In the meantime, a steward can fulfill the role of a Bureaucrat or Administrator.
# Wikimedia/How Wikidata works

Wikidata is a very complex website, and will require a page in this book to explain. Wikidata primarily consists of two things: items and properties. Items are prefixed with a Q, whereas properties are prefixed with a P. There are other pages on the wiki of course, but these are the basics. An item in itself is very complex, and may appear disorientating to a new member of the community.
Once a new item is created, it will be created with a Q prefix, and a number. This is basically the what number item it is, for example: Q10 is the tenth item, Q123 is the one-hundred-and-twenty-third item and so on and so forth. There are around 10,000,000 items available on Wikidata. The first part of an item is the label, basically the title of the item. There is one label for every language, not one for all languages.
Second is the description, describing the item. There is again one description per language. The third part is the list of aliases. There can be an unlimited amount of aliases per language, unlike labels and descriptions. The fourth part is the properties, where properties are defined. This can be date of birth, date of death, occupation, given name etc. There are many properties that can be defined, but not all properties apply to all items.
The fifth, and arguably the most important part of an item is the interwiki links. These link Wikipedia, Wikiquote, Wikivoyage and Wikisource pages to an item. Once a page is linked, a full list of different languages will appear down the sidebar of the desired article, allowing quick navigation between languages.
Properties are a lot less complex. They require a special right to create, this right can only be granted by administrators. Properties only consist of three parts, a label, a description, and a list of alternate aliases. That's all there is to it. Once created, these properties can be easily defined in any item. All properties defined can be referenced, but these do not have to be via URLs. The user can state that it has been imported from a Wikipedia, i.e. the English Wikipedia, Spanish Wikipedia, Dutch Wikipedia etc.
# Wikimedia/Images

Images are a key part of illustration in Wikimedia wikis. Most images are uploaded to the Wikimedia Commons, but some are uploaded to the site itself (mostly CD/DVD/game covers for copyright reasons). The Wikimedia Commons, the main upload centre for images, is meant to be used exclusively for content under a free license, including Content in the public domain, content under compatible free licenses, and content you created yourself and consent to release under a free license. To insert a photo for commons, you have to link it. I am going to use the example of a flower.
[[File:Flower.png|thumb|left|Caption]]
This code produces this result:
# Wikimedia/Contributing to this book

The content of this page is a proposal for the local Manual of Style of this book.

## Book structure

* Keep the book structure "flat" (i.e., no subchapters) for easy reading and linking.
* Use proper book title naming (i.e., Wikimedia/Subpage Name, not Wikimedia/Subpage name (administrative pages like this one being a notable exception).
* No transcluded categories (if templates are used, don't include categories, so that the book's category structure can be kept as simple as possible).

## General MOS

* This is a wikibook, so it should be worked on in the spirit of all wikibooks. Wikipedians should resist the urge to link every term or phrase, because wikibooks really just doesn't work that way. (If you feel you absolutely must link terms used here, use the [[w:term to be linked|]] format (don't forget the pipe at the end, which makes the "w:" disappear... this will be discussed further in chapter on the wikibooks MOS).

## Sections on particular Wikimedia projects

* "History" sections should start at the beginning, but need not be kept "up to the minute" (this is a book, not a newspaper).
* "Culture" sections should be as NPOV as possible, pointing out both the strengths and weaknesses of the communities built around each project.
* "MOS" sections (which need a better name) are about the policies and guidelines of each project. It should include the policies, how they evolved, why they were adopted, and why they are important. Remember that policy changes should not be discussed here, as this is just a book about Wikimedia, and shouldn't be mistaken for an administrative page.
# Wikimedia/How to Use Wikis
## Wiki culture

Each Wikimedia project has its own culture consisting of values which are commonly shared across Wikimedia and also some which have evolved which are specific to that particular project. These variances may be attributable to the different purposes, such as the distinction between a wiki-dictionary as opposed to a wiki-university, the latter emphasizing creativity whereas the former may emphasize accuracy.
Other differences may be attributable to differences between linguistic communities or peculiar accidents in the history of a particular project, each of which consists of individuals with different perspectives. Precedent in wiki project arbitration of disputes may differ in different projects, which might thereby have diametrically opposed policies. In most cases, however, there are broad similarities in wikimedia culture and etiquette, and the use thereof.
# Wikimedia/MOS

The content of this page is a proposal for the local Manual of Style of this book.

## Book structure

* Keep the book structure "flat" (i.e., no subchapters) for easy reading and linking.
* Use proper book title naming (i.e., Wikimedia/Subpage Name, not Wikimedia/Subpage name (administrative pages like this one being a notable exception).
* No transcluded categories (if templates are used, don't include categories, so that the book's category structure can be kept as simple as possible).

## General MOS

* This is a wikibook, so it should be worked on in the spirit of all wikibooks. Wikipedians should resist the urge to link every term or phrase, because wikibooks really just doesn't work that way. (If you feel you absolutely must link terms used here, use the [[w:term to be linked|]] format (don't forget the pipe at the end, which makes the "w:" disappear... this will be discussed further in chapter on the wikibooks MOS).

## Sections on particular Wikimedia projects

* "History" sections should start at the beginning, but need not be kept "up to the minute" (this is a book, not a newspaper).
* "Culture" sections should be as NPOV as possible, pointing out both the strengths and weaknesses of the communities built around each project.
* "MOS" sections (which need a better name) are about the policies and guidelines of each project. It should include the policies, how they evolved, why they were adopted, and why they are important. Remember that policy changes should not be discussed here, as this is just a book about Wikimedia, and shouldn't be mistaken for an administrative page.
Adapted from MOS of "Wikipedia" a Wikibook conceived and outlined by the user Johnny B.
# Science: An Elementary Teacher’s Guide/Chemistry Classroom Experiments
## Chemistry Classroom Experiments

Here are videos and websites about chemical reactions and experiments that can be done in the classroom:
* Magic Milk
* Elephant Toothpaste
* Here is a video of 10 cool experiments one can do at home. But always be safe!
* An Australian website with instructions for simple chemistry experiments.
* mix of chemistry and physics fun. Not all of these are appropriate for elementary classrooms!
* Having fun with a heavy gas, Sulfur Hexafluoride.
* Instructions for making "hot ice," sodium acetate, from vinegar and baking soda.
* Instructions for making slime
# Science: An Elementary Teacher’s Guide/Building Blocks of the Body

There are four main types of tissue in the body:
1. Muscle tissue, which forms all the muscles of the body.
2. Connective tissue, which supports body parts and hold them together, including bone, blood, tendons, ligaments, and cartilage.
3. Nerve tissue, which includes the brain, the spinal cord, and all nerves.
4. Epithelial tissue, which forms the outer skin and lines body cavities, such as the mouth, nose, stomach, intestines, and heart.
# Using KDE/History of KDE
## Brief History

KDE was founded in 1996 by Matthias Ettrich, who was then a student at the University of Tübingen. He found a number of things wrong with the UNIX desktop at that time. Among his qualms, outlined in a now-famous newsgroup post, were that none of the applications looked, felt, or worked alike to each other. He proposed the formation of not only a set of applications, but rather a desktop environment, in which users could expect things to look, feel, and work consistently. He also wanted to make this desktop easy to use. One of his complaints with desktop applications of the time was that his girlfriend could not use them. That post spurred a lot of interest, and the KDE project was born.
Matthias chose to use the Qt toolkit as the toolkit of choice of the KDE project. Other programmers quickly started developing KDE/Qt applications, and by early 1997, large and complex applications were being released. In mid-1997, the GNU project had concerns about the licensing of Qt, leading to their founding the GNOME Desktop project and Harmony, a now-abandoned project to clone Qt. Qt was later relicensed to provide the GNU General Public License as an option, which has mitigated these concerns. There is still considerable disagreement over the use of the full GPL for a library like Qt, and the restrictions this imposes on code linking to it, such as the KDE framework and any applications written for it. Both KDE and GNOME now participate in Freedesktop.org, an effort to standardize Unix desktop interoperability, although there is still some friendly competition between them.
# Using KDE/Glossary
## D
### Desktop Environment

TODO

## G
### GUI

Graphical User Interface
# Using KDE

This book that is aimed to help everyone from beginners to power users with KDE. It contains step-by-step tutorials and other general information.

## Table of Contents

* Introduction
* What is KDE?
** History of KDE
** Comparisons between KDE and other Desktop Environments
* Step-by-step installation guides
* Basics of Using KDE
* Applications
* Tips and Tricks
** Shortcuts
* Advanced Topics
* Glossary
* Additional Resources
# Using KDE/Additional Resources
## Links
### Official links

* The KDE website
* KDE.News, news announcements
* KDE TechBase
# Using KDE/Comparisons
## KDE and GNOME

* In terms of the basic desktop layout, KDE more-closely follows a Microsoft Windows style with a taskbar, start menu, and various other things. On the other hand, GNOME takes the Mac OS X approach, placing the menu bar on top of the screen and a separate bar for currently-open applications (the Task Bar).
* KDE and GNOME each have their own set of usability and accessibility guidelines:
** KDE Human Interface Guidelines
** GNOME Human Interface Guidelines
* KDE is built with the Qt toolkit while GNOME uses GTK.
* KDE is written in C++ and GNOME in C.
* While GTK is a very popular toolkit for Linux and thus most apps have better integration with GNOME, KDE's interface is normally considered slicker and more polished, possibly due to the underlying Qt toolkit.
# Using KDE/Advanced Topics
## System Settings

This module in KDE is where the user configures the desktop environment. It provides the user with a centralized and convenient way to configure all KDE settings.
It contains General and Advanced tabs, each tab contains objects that you can click to configure specific behaviour.
As you can see from the screenshot above, it's designed to be intuitive and simple to configure. For users familiar with Windows XP, this may seem similar to "Control Panel".
# Using KDE/Introduction

Using KDE covers:
* What KDE is
* How to use it
* The differences between KDE and other Desktop Environments
* Applications included with KDE
* Tips and tricks
* Resources for power users
What this guide is not :
* A guide to specific versions of KDE such as KDE for Debian, MacOS, or FreeBSD
* A developer's guide
* A guide to applications that are not part of or included with the KDE package. Those can be found elsewhere.
# Transportation Deployment Casebook/2022/Cuba
## Overview

XX

## Quantitative Analysis

XX

## S-Curve

XX

## The Havanan Suburban Railway
### Mode

XX

### Prior to the streetcar

XX

### Invention of the mode

XX

### Early Market Development

XX

### Policy during the birthing stage

XX

### Growth

XX

### Development

XX
# Transportation Deployment Casebook/2023

Streetcars deployed in:
* Philippine Islands
* Barbados
* Cuba
* Jamaica
* Trinidad
* Saskatchewan
* Panama
* Mexico
* Melbourne
* Glasgow
Air Transport System:
* U.S. Airliners
* Civilian freight in China
* Airlines of Cyprus
Taxi System:
Rail Transit Networks:
* London Underground
* Shenzhen Metro
* Shanghai Maglev
* Shinkansen
* Rail Development in Germany (1835 - 1918)
* Vancouver SkyTrain
* Tianjin
* Manchester Metrolink
* China railway
* Saskatchewan Railway
* TGV
* Hong Kong MTR
Road Transportation Network:
Ferry Transportation Network:
Bus Transportation Network:
# Vietnamese/Glossary/A-K

This glossary covers only the words used in this textbook. For a more complete listing of Vietnamese words and phrases, please see Wiktionary.

## A
### anh

    man;
    you (to a male who is the same age as the speaker)

## B
### bà

    woman;
    you (formal; to a female who is older than the speaker, or to the speaker's grandmother);
    grandmother

### bác

    parents's older sister of brother

### bạn

    friend;
    you (informal, but not casual; a general-purpose version; use with caution)

## C
### cha

    father

### chị

    you (informal; to a female who is the same age as or older than the speaker)

### chim

    bird
    penis

### con

    child
    you (from an adult to a child)

### chó

    dog

### Cô

    Mrs.; (formal)
    aunt (father younger sister)

## E
### em

    you (to a female who is the same age as the speaker, or to a person who is younger than the speaker, such as a child)

## D
### Dì

    aunt (mother youger sister)

## G
### gà

    chicken