Boost.Localeが採択されました - Faith and Brave

Boost.Localeライブラリが採択されました。
レビュー結果は以下：

4/7〜4/16の間で行われたArtyom BeilisのBoost.Localeライブラリのレビューが終了した。
15人が参加し、採択に関して10人が賛成し、5人が反対した。圧倒的ではないが、2対1の過半数は、明確にリストのコンセンサスを示す。そのため：

Boost.LocaleライブラリをBoostに採択する。

詳細は、賛成票から始め、それらのレビューを受け取った順に続く：

John Bytheway
Steven Watanabe
Sebastian Redl
Fabio Fracassi ("possibly conditional")
Noah Roberts
Steve Bush
Volker Lukas
Paul A. Bristow
Matus Chochlik
Gevorg Voskanyan

反対：

Ryou Ezoe
Phil Endecott (but "borderline")
Edward Diener
Mathias Gaunard
Vincente BOTET ("count my vote as 1/2 or 1/4 vote")

単に問題のリストを挙げ、投票を含めなかったDarren Cookからのレビューが初期にあった。

ライブラリ周辺の多くの議論と、詳しく述べられた多くの問題があった。主なもの(数人のレビュアーによって繰り返されたメジャーなもの)は、レビュアー、およびArtyomのレスポンスのイニシャルを加えて、以下に要約する。私は、議論に緊密についていったが、これらがレビュー自体の中で提起された問題にすぎないことに注意。

Issue： date_timeインタフェースは、enumを期間に使用する。それは他の日付／時間ライブラリでしがちで一貫しないエラーだ(JB)。
Response：取り組もう。

Issue：リファレンスドキュメンテーションは、より多くの詳細、あるいは明確でない部分を必要とする。ドキュメントの中で使用される用語が定義されていないか、または簡潔に定義されすぎている。アイテムがドキュメントから定義されるヘッダを見つけることができない(JB, SW, FF, PE, ED, MC)。
Response：取り組もう。

Issue：ドキュメントにprev/nextリンクがない。あるいは、チュートリアルを容易にナビゲートすることができない(DC, JB・Sr, FF, MC)。
Response：取り組もう。

Issue：出力を含んでいる例がほとんどない(JB)。
Response：取り組もう。

Issue：アジア言語の例がない。このライブラリはそれらなしでは、外見上ではない設計の傷があるかもしれない(DC)。
Response： Artyomは、彼がそういった例を加えていることを私に(プライベートに)示した(CN)

Issue：翻訳システムは、それを英語中心にしてnarrow文字のタグを要求する(RE, ED)。
Response：このライブラリは、最もポピュラーなものと、最も広く使用されたメッセージカタログフォーマットを実装する。これは完全ではないが、それは現在利用可能な最良のシステムである。あなたが実際にWindows環境でワイド文字言語を使用しなければならないならば、workaroundがありえるかもしれない。

Issue： wchar_t/UTF-16のサポートが不明瞭(RE, ED)。
Response：ワイド文字は全面的にサポートされる。

Issue：バックエンドとして、Win32 APIをサポートしていない(RE)。
Response：それは誤解。Win32 APIバックエンドは全面的にサポートされる。

Issue： boost::locale::formatは、boost::formatと互換性をもたない(FF, NR)。
Response： boost::formatは、ローカライズで使用するために制限され、あらゆるエラーを投げる。それは、トランスレータエラーがプログラムを壊すかもしれないことを意味する。

Issue： boost::locale::date_timeは、boost::date_timeと互換性をもたない(FF)。
Response：ロケールの独自性と、非グレゴリオ暦サポートにより必要であることの間の違いで、避けられない結果。

Issue： ICUを使用する場合、境界分析は利用可能(FF)。
Response：現在、ICUバックエンドだけが適切な境界分析をサポートする。

Issue：文字列を抽出し、それらを翻訳するために必要とされるツールチェインについてのドキュメンテーション、あるいはバージョンが必要(FF, NR)。
Response：取り組もう。

Issue： GPL/LGPLライセンスツールに依存すること、すべてのプラットフォーム上のそれらの有効性に対する懸念、それらのツールのBoostバージョンを書くことを推奨する(NR)。
Response：これらを再実装することは、非自明で、不必要である。これらのツールのための許可は、それらで開発されたプログラムには影響しない。これら全ては、全てのプラットフォームで利用可能。Windowsのために最新バージョンを得る明示的な説明を書き加えよう。

Issue：言語とエンコーディングのためのシンボル文字列を使用してほしい。そうすれば、コンパイル時エラーにできる最も一般的なものはシンボルであるべき(PE)。
Response：多数の文字エンコーディング、およびロケールがある。また、最も一般的なものがどれか決める方法はない。全てのエンコーディングは全てのバックエンド、あるいはOS構成にサポートされるとは限らない。名前は大文字／小文字と、非英数文字を無視する。それらから生成することができたエラーを最小化するべきだろう。utf_to_utf変換エンコーディングが加えられるだろう。

Issue：変換でのエラーハンドリングが非常に基礎的だ(PE)。
Response：バックエンドの避けられない制限。

Issue：コードはもっとコメントを使用してほしい(PE, VL)。
Response：今後取り組もう。

Issue：あるドキュメンテーション語法は紛らわしい。あるいは、英語のネイティブスピーカーの入力を使うべき(SR, VL)。
Response：発見したら取り組もう。

Issue：有効な言語、国、エンコーディング、あるいは様々な文字列のリストがない(ED)。
Response：標準ISO-639およびISO-3166でリスト化されている。これはライブラリのドキュメントで参考文献として記載される。これらの標準は時々更新され、最新情報のために直接引用されるべきだ。

Issue：連続する完全なインメモリ文字列でしか動かない(MG)。
Response：現在のバックエンドは全てこれを要求する。また、それはユースケースの大部分を満たす。

Issue：境界分析は、全ての文字列を通り抜け、位置のvectorを返す(MG)。
Response：完全ではないが、与えられた終端の制限であり、これは合理的だ。

Issue：ライブラリのインタフェースが十分にジェネリックでなく、それらがラップライブラリに十分に依存しないわけでもない(VB)。
Response：インタフェースはi18nライブラリのそれと同様で、できる限り少ない仮定をしなければならない。これは変更すべきではない。

Issue： date-timeコードは、Boost.DateTimeへマージされるべきだ(VB)。
Response： date-timeコードは、その性質によってロケール依存で、Boost.Localeにおいてより自然である。Boost.Localeライブラリがするもの全てのためにBoost.DateTimeを更新することは、多くの作業を要求するだろう。そしてそれは終始、グレゴリオ暦だけが実装された。他のものをオーバーラップさせるBoostライブラリがある。そのため、これは真新しいことではない。