Fix typo "serailizers" to "serializers"

docs/topics/3.0-announcement.md

@@ -189,13 +189,13 @@ You can either return `non_field_errors` from the validate method by raising a s
 
     def validate(self, attrs):
         # serializer.errors == {'non_field_errors': ['A non field error']}
-        raise serailizers.ValidationError('A non field error')
+        raise serializers.ValidationError('A non field error')
 
 Alternatively if you want the errors to be against a specific field, use a dictionary of when instantiating the `ValidationError`, like so:
 
     def validate(self, attrs):
         # serializer.errors == {'my_field': ['A field error']}
-        raise serailizers.ValidationError({'my_field': 'A field error'})
+        raise serializers.ValidationError({'my_field': 'A field error'})
 
 This ensures you can still write validation that compares all the input fields, but that marks the error against a particular field.
 
@@ -303,7 +303,7 @@ Alternatively, specify the field explicitly on the serializer class:
             model = MyModel
             fields = ('id', 'email', 'notes', 'is_admin')
 
-The `read_only_fields` option remains as a convenient shortcut for the more common case. 
+The `read_only_fields` option remains as a convenient shortcut for the more common case.
 
 #### Changes to `HyperlinkedModelSerializer`.
 
@@ -364,7 +364,7 @@ The `ListSerializer` class has now been added, and allows you to create base ser
     class MultipleUserSerializer(ListSerializer):
         child = UserSerializer()
 
-You can also still use the `many=True` argument to serializer classes. It's worth noting that `many=True` argument transparently creates a `ListSerializer` instance, allowing the validation logic for list and non-list data to be cleanly separated in the REST framework codebase. 
+You can also still use the `many=True` argument to serializer classes. It's worth noting that `many=True` argument transparently creates a `ListSerializer` instance, allowing the validation logic for list and non-list data to be cleanly separated in the REST framework codebase.
 
 You will typically want to *continue to use the existing `many=True` flag* rather than declaring `ListSerializer` classes explicitly, but declaring the classes explicitly can be useful if you need to write custom `create` or `update` methods for bulk updates, or provide for other custom behavior.
 
@@ -436,7 +436,7 @@ Here's a complete example of our previous `HighScoreSerializer`, that's been upd
         def to_internal_value(self, data):
             score = data.get('score')
             player_name = data.get('player_name')
-            
+
             # Perform the data validation.
             if not score:
                 raise ValidationError({
@@ -450,7 +450,7 @@ Here's a complete example of our previous `HighScoreSerializer`, that's been upd
                 raise ValidationError({
                     'player_name': 'May not be more than 10 characters.'
                 })
- 
+
 			# Return the validated values. This will be available as
 			# the `.validated_data` property.
             return {
@@ -463,7 +463,7 @@ Here's a complete example of our previous `HighScoreSerializer`, that's been upd
                 'score': obj.score,
                 'player_name': obj.player_name
             }
-        
+
         def create(self, validated_data):
             return HighScore.objects.create(**validated_data)
 
@@ -471,7 +471,7 @@ Here's a complete example of our previous `HighScoreSerializer`, that's been upd
 
 The `BaseSerializer` class is also useful if you want to implement new generic serializer classes for dealing with particular serialization styles, or for integrating with alternative storage backends.
 
-The following class is an example of a generic serializer that can handle coercing aribitrary objects into primitive representations. 
+The following class is an example of a generic serializer that can handle coercing aribitrary objects into primitive representations.
 
     class ObjectSerializer(serializers.BaseSerializer):
         """
@@ -542,7 +542,7 @@ The `default` argument is also available and always implies that the field is no
 
 #### Coercing output types.
 
-The previous field implementations did not forcibly coerce returned values into the correct type in many cases. For example, an `IntegerField` would return a string output if the attribute value was a string. We now more strictly coerce to the correct return type, leading to more constrained and expected behavior. 
+The previous field implementations did not forcibly coerce returned values into the correct type in many cases. For example, an `IntegerField` would return a string output if the attribute value was a string. We now more strictly coerce to the correct return type, leading to more constrained and expected behavior.
 
 #### The `ListField` class.
 
@@ -695,7 +695,7 @@ These classes are documented in the [Validators](../api-guide/validators.md) sec
 
 The view logic for the default method handlers has been significantly simplified, due to the new serializers API.
 
-#### Changes to pre/post save hooks. 
+#### Changes to pre/post save hooks.
 
 The `pre_save` and `post_save` hooks no longer exist, but are replaced with `perform_create(self, serializer)` and `perform_update(self, serializer)`.
 
@@ -887,4 +887,4 @@ The 3.2 release is planned to introduce an alternative admin-style interface to
 
 You can follow development on the GitHub site, where we use [milestones to indicate planning timescales](https://github.com/tomchristie/django-rest-framework/milestones).
 
-[mixins.py]: https://github.com/tomchristie/django-rest-framework/blob/master/rest_framework/mixins.py
+[mixins.py]: https://github.com/tomchristie/django-rest-framework/blob/master/rest_framework/mixins.py