Replaced smart_* by force_* calls whenever possible

The smart_* version should only be used when a lazy string should keep
its lazy status.

2 files changed, 2 insertions, 2 deletions

diff --git a/docs/ref/databases.txt b/docs/ref/databases.txt
index 6d705beb66..6412316a2d 100644
--- a/docs/ref/databases.txt
+++ b/docs/ref/databases.txt
@@ -369,7 +369,7 @@ to you, the developer, to handle the fact that you will receive bytestrings if
 you configure your table(s) to use ``utf8_bin`` collation. Django itself should
 mostly work smoothly with such columns (except for the ``contrib.sessions``
 ``Session`` and ``contrib.admin`` ``LogEntry`` tables described below), but
-your code must be prepared to call ``django.utils.encoding.smart_text()`` at
+your code must be prepared to call ``django.utils.encoding.force_text()`` at
 times if it really wants to work with consistent data -- Django will not do
 this for you (the database backend layer and the model population layer are
 separated internally so the database layer doesn't know it needs to make this
diff --git a/docs/ref/unicode.txt b/docs/ref/unicode.txt
index d09431cbee..742a5c0d78 100644
--- a/docs/ref/unicode.txt
+++ b/docs/ref/unicode.txt
@@ -163,7 +163,7 @@ for converting back and forth between Unicode and bytestrings.
   slightly different semantics from Python's builtin ``str()`` function,
   but the difference is needed in a few places within Django's internals.
 
-Normally, you'll only need to use ``smart_text()``. Call it as early as
+Normally, you'll only need to use ``force_text()``. Call it as early as
 possible on any input data that might be either Unicode or a bytestring, and
 from then on, you can treat the result as always being Unicode.