rm obsolete TODO,  Anna did this!
GITHUB_BREAKING_CHANGES=none
@@ -29,70 +29,6 @@ Cons:
works in the optimizer
-## Eliminate soy_js build rules in favor of af_soy_library
-
-We have already done a lot of work here, e.g. we added support to genjsdeps and
-xaze so that teams can theoretically migrate
-
-However, there is a major issue with translations. `soy_js` (by default) uses
-jscompiler for translations which means that jscompiler calculates message ids
-(specifically it doesn't set `--goog_messages_are_external`). `af_soy_library`
-uses a custom message extraction and id algorithm. This means that by switching
-to `af_soy_library` you will (without intervention):
-
-* break all translations
-* break message extraction
-
-It is somewhat manageable to fix this on a project by project basis if you are
-knowledgeable about translations, but there is actually no way to do it without
-at least temporarily breaking translations.
-
-To actually enable migrations we need to make things easier
-
-* add a way to migrate translations between ids in the translation console:
- b/123764883
-* change soy to output some hint to the jscompiler that we want to migrate IDs
-* change jcompiler to actually interpret this hint
-* change `soy_js` to output extra xmb files as a side effect of the build to
- make sure extraction won't break
-* wait some amount of time for all projects to extract and dump translations
- (according to TC there is no build horizon like concept that we could rely
- on..., but we can manually trigger extractions for projects we don't own so
- we could theoretically do this ourselves)
-* change the default of `goog_messages_are_external` to be always true
-
-If we do all that then we still need to change how messages are extracted.
-`af_soy_library` requires a custom rule `af_soy_genmsg` to do message
-extraction, so when migrating a project we would also have to add
-`af_soy_genmsg` rules. Luckily, these rules have been retrofitted to use a blaze
-aspect, so you just need to point them at a `js_binary` rule. In theory we could
-change the jscompiler to just extract these 'external' messages, but currently
-the jscompiler always adds a synthetic meaning attribute which breaks message
-merging.
-
-If we somehow did all of that, then we could migrate `soy_js` rules to
-`af_soy_library`.
-
-Pros:
-
-* Makes features easier to add since there are fewer configurations. For
- example:
- * would make it possible to generate es6 modules
- * would make it possible for soy itself to add a file based import syntax
- * improve message sharing, right now some projects (like gmail) are paying
- for every message to be translated twice due to this issue
-* unlock other improvements in the ecosystem (e.g. if b/123764883 is fixed,
- then jscompiler can remove the `tc_project_id` flag which would improve
- message sharing across projects)
-* Reduced support burden
-
-Cons:
-
-* This is a truly monumental amount of work.
-* af_soy_library brings in extra deps for js only projects
-* even after all this users still need extra build rules (`af_soy_genmsg`)
- that are easy to forget.
-
## Move af_soy_library to `third_party/java/builddefs` and rename to `soy_library`
A prerequisite for maybe bazel-ifying it
