Introduction

moses.ini is the central runtime configuration file for the Moses statistical machine translation decoder. It tells the decoder which models to load, where those model files live, and how strongly each feature should influence scoring. The file can look intimidating at first, but it is easier to understand once you treat it as a list of named feature blocks plus a matching set of weights.

What moses.ini Controls

A typical moses.ini file describes:

• decoder settings
• phrase or lexical translation models
• language models
• reordering models
• feature weights
• optional penalties or sparse features

In most workflows, the file is generated by the Moses training or tuning pipeline rather than written entirely by hand. Even so, understanding the structure matters when you need to debug a broken path, adjust feature weights, or swap in a new model artifact.

The Section-Based Structure

The file is organized into bracketed sections. A simplified example looks like this:

1[input-factors]
20
3
4[mapping]
50 T 0
6
7[feature]
8PhraseDictionaryMemory name=TranslationModel0 num-features=4 path=/models/phrase-table.gz input-factor=0 output-factor=0
9KENLM name=LM0 factor=0 path=/models/lm.arpa order=3
10WordPenalty
11UnknownWordPenalty
12
13[weight]
14TranslationModel0= 0.2 0.2 0.2 0.2
15LM0= 0.5
16WordPenalty= -1.0
17UnknownWordPenalty= -1.0

The important pattern is that features are declared in one section and weighted in another.

The Most Important Sections

feature

This section declares the models and score-producing components the decoder should use. Common lines refer to:

• phrase tables
• language models such as KenLM
• lexical reordering models
• penalties such as word penalty or distortion penalty

Each feature often has a name= field, and that name is later referenced in the weight section.

weight

This section assigns numeric weights to the features. During decoding, Moses combines the feature scores with these weights to rank candidate translations.

If a model loads successfully but translation quality looks wrong, mismatched or badly tuned weights are often the issue.

mapping and factor sections

These lines are important in factor-based translation setups. They describe which input and output factors the decoder should connect. In a simple phrase-based configuration, they may remain minimal. In more advanced factored models, these sections matter much more.

How Feature and Weight Names Must Match

A common source of confusion is that feature declarations and weight entries are linked by name.

Example:

1[feature]
2KENLM name=LM0 factor=0 path=/models/lm.arpa order=3
3
4[weight]
5LM0= 0.4

If the names do not align, the decoder configuration becomes inconsistent. That is why hand-editing moses.ini requires care.

Common Manual Edits

Although the file is often generated automatically, people still edit it by hand for practical reasons:

• moving model files to a new directory and updating path= entries
• swapping one language model for another
• adjusting a few weights after tuning experiments
• disabling or removing a feature line temporarily

When doing this, treat the file as a structured configuration artifact, not as free-form notes. One broken path or mismatched weight name can stop decoding entirely.

Running Moses With the File

The standard usage pattern is to point the decoder at the configuration file:

moses -f /path/to/moses.ini < input.txt > output.txt

That command line is why moses.ini is so central. It is effectively the recipe the decoder follows at runtime.

How to Read a Generated File Without Getting Lost

A practical approach is:

1. find the [feature] section first
2. identify the major model components and their names
3. jump to [weight] and confirm that each named feature has the expected weight entry
4. check all path= fields if the decoder cannot load resources

This is usually faster than reading the file top to bottom as if it were prose.

Common Pitfalls

• Editing path= values without checking that the referenced model files actually exist.
• Changing feature names in one section but not the matching weight entries.
• Treating generated moses.ini files as interchangeable across differently trained model directories.
• Trying to hand-author a complex factored configuration without first understanding the generated baseline.
• Assuming poor translation quality always comes from model files when weight settings may be the real issue.

Summary

• 'moses.ini is the main decoder configuration file for Moses.'
• It defines features, model paths, and the weights used during scoring.
• The [feature] and [weight] sections are the most important places to understand first.
• Most real-world edits involve paths, model swaps, or weight changes.
• Read the file as a structured mapping between named features and their scoring parameters.