I just released v0.3.1 with the following change:
||) for pluralization and promotes the use of a shared msgid for singular/plural forms (thanks @dkuku for the idea)Note: The separator will still work in the v0.3.x release, but it will be removed in v0.4.x (unless there is a good reason to keep it).
I just released v0.3.2 with the following fix:
I also noticed that there is an issue when using explicit keys in HEEx templates:
# this works
~H"""
<h1>{~t"Hello, #{@name}!"}</h1>
<div>{~t"You have #{@count} notification(s)"N}</div>
""
# this DOES NOT work
~H"""
<h1>{~t"Hello, #{name :: @user.name}!"}</h1>
<div>{~t"You have #{count :: length(@notifications)} notification(s)"N}</div>
"""
The reason for this is that the HEEx engine does not transform assigns on the right side of :: operators, which are usually used for binary modifiers (see Phoenix LiveView source).
See issue #23 for more information. I’m honestly not sure if this is a bug in LiveView that could be fixed or if I made a bad choice using the :: operator for explicit keys.
If anyone with more knowledge than me has some insights, some guidance would be appreciated! 
Would #{count = length(@notifications)} help? I suppose :: is similar enough generating binaries with <<x::y>> but otherwise looked odd to me inside ~t. = would bring other perhaps unwanted connotations so perhaps it’s not ideal either.
I haven’t looked at the implementation yet but I’d think macro should expand so that HEEx just sees RHS, while somehow preserving gettext extraction behavior if possible.
Thanks @wojtekmach! I used :: because I liked the similarity to typespecs, but if = just works, I think it is worth to change.
Great, using = works as expected! 
I already updated and merged the PR.
I’m sorry for introducing another breaking change, but with these issues ironed out, I think it should soon be a bit more stable 
I just released v0.4.0 with the following breaking changes:
:pluralization option from use GettextSigils sigils config and application config#{foo :: bar} to #{foo = bar} to support HEEx assigns (thanks @wojtekmach)@foo => %{foo})I apologize for introducing another breaking change with this release, but I hope to have a bit more stability now that some major issues have been solved! 
This horse may have left the barn. However, you may consider ~gtxt instead of ‘~t’ for clarity:
# replacing 'gettext()' with '~gtxt()'
~gtxt"Hello, #{user.name}"
As, ~t could mean anything.
Sidenote: I once suggested using sigils in function definitions to replace ‘do’ for Elixir code back in 2017 during the Elixir v.1 “syntax wars”.
archive: This was the syntax I proposed for the next version of Elixir almost a decade ago.
# replacing 'do' with '~>'
# note: 'defm' replaces 'defmodule'
defm areas ~>
# also note: docstrings are bounded by '|: ... :|'
|: Calculates the area of a rectangle given its length and width :|
# function definition: 'area_rect/2'
def area_rect (length, width) ~>
length * width
... # replaces 'end'
...
Notice there are no ‘end’ block delimiters. I had also proposed that ‘…’ could replace ‘end’ to close the function or module block. (coughs, clears throat) Maybe someday 
.
@josevalim had some interesting and pragmatic reasons for sticking with the Elixir syntax having fought with the syntax question privately at the language’s inception (see the HN discussion: https://news.ycombinator.com/item?id=8672996 ).
Nevertheless, I’m happy to see @josevalim now appreciates that sigils can make verbose Elixir code more succinct … and beautiful
(For more on the Elixir Syntax Wars see here: https://forum.elixirforum.com/t/discussion-about-syntax-preferences-split-posts/3436)
You’re right given AST pragmatics (i.e., parser simplicity). Instead of a separate sigil library, one may need to consider ditching the sigil and just replacing “gettext’ with “gtxt”. We really should move away from single character references in code just on the basis of the ambiguity nightmare these can cause for code maintainers. That’s the kernel of my earlier proposal.
Thanks for your feedback! I really appreciate critical feedback. I was not aware of the early language wars and (maybe naively) just picked what looked best (at least to me).
I actually considered using ~GTXT or ~GT for clarity reasons, but decided against it because my goal was keeping the visual noise as low as possible. I wanted to avoid things like this:
~GTXT"No"
# compared to
~t"No"
I also remembered in Rails you could use t("...") and I liked the parallel. I can also say that because we have already used the ~t sigil over several years internally at my company, it’s something you get used to very quickly and everybody in the team recognises this as a translation. But that, of course, is just us in our small bubble and your concern is still valid.
All that said, I’m open for suggestions for 1.x
Cheers!