// intl extension produces non null-terminated
// strings. Appending '' fixes it so that it doesn't generate
// a warning on each access in debug php.
- wfSuppressWarnings();
+ MediaWiki\suppressWarnings();
$key = $this->mainCollator->getSortKey( $string ) . '';
- wfRestoreWarnings();
+ MediaWiki\restoreWarnings();
return $key;
}
function getPrimarySortKey( $string ) {
- wfSuppressWarnings();
+ MediaWiki\suppressWarnings();
$key = $this->primaryCollator->getSortKey( $string ) . '';
- wfRestoreWarnings();
+ MediaWiki\restoreWarnings();
return $key;
}
}
}
- // Sort the letters.
- //
- // It's impossible to have the precompiled data file properly sorted,
- // because the sort order changes depending on ICU version. If the
- // array is not properly sorted, the binary search will return random
- // results.
- //
- // We also take this opportunity to remove primary collisions.
+ /* Sort the letters.
+ *
+ * It's impossible to have the precompiled data file properly sorted,
+ * because the sort order changes depending on ICU version. If the
+ * array is not properly sorted, the binary search will return random
+ * results.
+ *
+ * We also take this opportunity to remove primary collisions.
+ */
$letterMap = array();
foreach ( $letters as $letter ) {
$key = $this->getPrimarySortKey( $letter );
}
}
ksort( $letterMap, SORT_STRING );
- // Remove duplicate prefixes. Basically if something has a sortkey
- // which is a prefix of some other sortkey, then it is an
- // expansion and probably should not be considered a section
- // header.
- //
- // For example 'þ' is sometimes sorted as if it is the letters
- // 'th'. Other times it is its own primary element. Another
- // example is '₨'. Sometimes its a currency symbol. Sometimes it
- // is an 'R' followed by an 's'.
- //
- // Additionally an expanded element should always sort directly
- // after its first element due to they way sortkeys work.
- //
- // UCA sortkey elements are of variable length but no collation
- // element should be a prefix of some other element, so I think
- // this is safe. See:
- // * https://ssl.icu-project.org/repos/icu/icuhtml/trunk/design/collation/ICU_collation_design.htm
- // * http://site.icu-project.org/design/collation/uca-weight-allocation
- //
- // Additionally, there is something called primary compression to
- // worry about. Basically, if you have two primary elements that
- // are more than one byte and both start with the same byte then
- // the first byte is dropped on the second primary. Additionally
- // either \x03 or \xFF may be added to mean that the next primary
- // does not start with the first byte of the first primary.
- //
- // This shouldn't matter much, as the first primary is not
- // changed, and that is what we are comparing against.
- //
- // tl;dr: This makes some assumptions about how icu implements
- // collations. It seems incredibly unlikely these assumptions
- // will change, but nonetheless they are assumptions.
+
+ /* Remove duplicate prefixes. Basically if something has a sortkey
+ * which is a prefix of some other sortkey, then it is an
+ * expansion and probably should not be considered a section
+ * header.
+ *
+ * For example 'þ' is sometimes sorted as if it is the letters
+ * 'th'. Other times it is its own primary element. Another
+ * example is '₨'. Sometimes its a currency symbol. Sometimes it
+ * is an 'R' followed by an 's'.
+ *
+ * Additionally an expanded element should always sort directly
+ * after its first element due to they way sortkeys work.
+ *
+ * UCA sortkey elements are of variable length but no collation
+ * element should be a prefix of some other element, so I think
+ * this is safe. See:
+ * - https://ssl.icu-project.org/repos/icu/icuhtml/trunk/design/collation/ICU_collation_design.htm
+ * - http://site.icu-project.org/design/collation/uca-weight-allocation
+ *
+ * Additionally, there is something called primary compression to
+ * worry about. Basically, if you have two primary elements that
+ * are more than one byte and both start with the same byte then
+ * the first byte is dropped on the second primary. Additionally
+ * either \x03 or \xFF may be added to mean that the next primary
+ * does not start with the first byte of the first primary.
+ *
+ * This shouldn't matter much, as the first primary is not
+ * changed, and that is what we are comparing against.
+ *
+ * tl;dr: This makes some assumptions about how icu implements
+ * collations. It seems incredibly unlikely these assumptions
+ * will change, but nonetheless they are assumptions.
+ */
$prev = false;
$duplicatePrefixes = array();
// Save to cache
$this->firstLetterData = $data;
- $cache->set( $cacheKey, $data, 86400 * 7 /* 1 week */ );
+ $cache->set( $cacheKey, $data, $cache::TTL_WEEK );
return $data;
}