Myanmar Tools Laravel Package

Technical Evaluation

Architecture fit

• Pure-PHP implementation of Google's Myanmar Tools: no native extensions, no external service calls, no runtime daemons. Drops into a Laravel app as a Composer dependency and executes in-process.
• Two capabilities matter: ZawgyiDetector (returns a 0.0–1.0 probability that a string is Zawgyi-One rather than Unicode) and Rabbit (converts Zawgyi-One → Unicode). Conversion is one-directional; there is no supported Unicode → Zawgyi path, which constrains any "round-trip" requirement.
• Zero framework coupling — no service provider, facade, config, or migration. Integration cost sits entirely in our own wrapper layer, which is also an advantage: nothing to unwind later.
• Algorithm is a trained statistical model loaded from a bundled data file, not a heuristic regex. That is the right design for an encoding-detection problem, but it makes behaviour opaque and threshold-dependent.

Integration feasibility

• Straightforward: composer require googlei18n/myanmar-tools, wrap in a singleton service, bind in a provider, call from validation rules, model mutators, import pipelines, or middleware.
• Determinism is good for testing: same input → same probability, so golden-file tests over a labelled Myanmar corpus are viable.
• The main feasibility blocker is packaging hygiene, not logic.

Technical risk

• Staleness (high). Last release 2020-12-29. Composer php constraints almost certainly predate PHP 8.2/8.3 and will likely conflict with a current Laravel 10/11 dependency graph. Expect to fork, relax constraints, and run the PHP test suite ourselves before we can rely on it.
• License flag (medium, procedural). Metadata reports NOASSERTION; the upstream repo is Apache-2.0. Apache-2.0 is commercially safe, but the flag will block release gates until legal clears it in writing. Budget a week, not a day.
• Model file distribution (medium). Detection accuracy depends on a data file shipped inside the package. Verify it survives composer install --no-dev, CI artifact packaging, and Docker layer copies; a missing model is a silent accuracy collapse, not a crash.
• Accuracy in mixed-script reality (medium). Probabilities near the boundary are unreliable. Default thresholds are tuned for "is this whole message Zawgyi?" not "clean this user-typed field." Our data will contain partially converted, emoji-laden, and multi-language strings.
• Performance is unquantified for our payload sizes (low–medium). Pure-PHP scanning is CPU-bound. Fine for short profile fields; risky inside a bulk import or a hot read path.

Key questions

1. Which PHP versions does the current constraint actually permit, and what is the cost of a maintained internal fork?
2. Is the shipped model identical to the Java reference implementation's, and how do we validate parity?
3. What precision/recall do we get on our corpus at threshold 0.95 vs 0.85?
4. What is the p99 cost per 1 KB of Myanmar text in our production PHP build?
5. Can we store the raw original alongside the converted value to make conversion reversible?
6. Legal: is the Apache-2.0 attribution requirement satisfied by our distribution model?

Integration Approach

Stack fit

• Works with Laravel 8–11 after constraint adjustment; no Octane/Swoole incompatibility expected since there is no mutable global state, but confirm the detector instance is safe to hold as a singleton or is cheap to reconstruct.
• Natural insertion points: FormRequest custom rule (detect-and-reject or detect-and-normalize), Eloquent mutators/observers for write-time normalization, queued jobs for bulk backfill, and Laravel Scout indexers to normalize before indexing so search matches both encodings.

Migration path

• Phase 0 — spike: install in a scratch branch, resolve PHP constraints, benchmark on a 5k-row extract of real Myanmar text, and hand-label a sample with a native-speaker reviewer to pick a threshold.
• Phase 1 — shadow mode: run detection on every Myanmar-containing write, log probability and decision, convert nothing. This produces the corpus and the false-positive rate we cannot get any other way.
• Phase 2 — convert on write for one surface (e.g. new support tickets or new listings), behind a config flag.
• Phase 3 — backfill history with chunked queued jobs, idempotent and resumable, writing the original to a *_raw column.
• Phase 4 — widen to all surfaces; keep a kill switch.

Compatibility

• Prefer a pinned fork under our own VCS namespace over --ignore-platform-reqs in production. Relaxing constraints locally is a one-line change and removes the upgrade dead-end.
• Guard every call with a cheap prefilter (preg_match('/[\x{1000}-\x{109F}\x{AA60}-\x{AA7F}]/u')) so non-Myanmar traffic pays near-zero cost.
• Wrap the library in one internal MyanmarText service and never call the vendor classes directly — that isolates us from an unmaintained dependency.

Sequencing

License clearance and the fork both precede any production code. Detection accuracy measurement precedes conversion rollout. Backfill precedes removing legacy display workarounds. Do not parallelize Phase 1 and Phase 2; the shadow-mode data is the whole point.

Operational Impact

Maintenance

• Upstream is effectively dormant — five years without a release, maintained as a side project of Google's i18n effort with no committed roadmap. Treat this as vendored code we own, not a live dependency. Budget a few days a year for PHP-version compatibility and model refreshes.
• The API surface is two classes; the maintenance burden is low. The domain-knowledge burden is not.

Support

• Community-only: GitHub issues, no SLA, no security response process. Acceptable for a non-security-critical text-normalization concern; unacceptable as a single point of failure on a checkout or identity path without our own tests.
• Internal ownership must sit with a named engineer plus a Myanmar-speaking reviewer for accuracy regressions. Without the reviewer, we cannot detect quality drift.

Scaling

• CPU-bound and per-request. At low-to-moderate Myanmar volume (thousands of writes/day) this is noise. For bulk remediation or high-throughput ingestion, route through queues and consider the C++ or JS implementations as an out-of-band service if profiling shows a bottleneck.
• Memory is dominated by the model file; measure the resident cost per worker before sizing queue workers.

Failure modes

• Model file absent or unreadable → detector degrades or throws on every Myanmar string; health-check it at boot.
• Invalid UTF-8 input → exceptions in the conversion path; sanitize before calling.
• False positives silently corrupting correct Unicode text — the worst outcome, because it is invisible to non-readers. Mitigate with a high threshold, raw-value retention, and sampled human review.
• False negatives leaving Zawgyi in place — a persistence bug, not an outage, but it defeats the purpose.
• Mixed/partially converted strings producing garbled output; detect per-field, not per-record.
• Long strings causing request timeouts in synchronous paths; cap input length and defer the rest.

Ramp-up

• Engineering ramp-up is hours: two classes, obvious signatures, easy to unit test.
• Product ramp-up is the real cost: threshold selection and accuracy sign-off require a labelled corpus and a native reader. Plan one to two weeks of calendar time for that gate, and keep a feature flag plus the *_raw column permanently so a bad threshold is a config rollback rather than a data-loss incident.